Skip to end of metadata
Go to start of metadata


  • 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

      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

      We have

      Louvre, Institution, Museum


      Louvre (Institution, Museum)
    • Acquisition (example I did for BM RForms): instead of
          transferred title from
               bequeathed by

      we'd use

          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):
    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):

    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


  • 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: 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
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: : new mockup with notes

Vlado notes:

  • What's the best browser to use for 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.
  • 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. 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

  • 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

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 17, 2012

    In tabular view, how does the selected field and the joiner look like for items that are not at the end of the line?

    (The "Etcetera" value in the example.)

    1. Sep 17, 2012

      The joiner should surround the item with the same margins, so would be indented.

      1. Sep 17, 2012

        But on the right it would pass through the rightmost columns. Please, draw a pic with column selected and a joiner in tabular view.

        1. Sep 17, 2012

          Will do once the design is agreed by everyone. The right side follows the indent and the left stays in place, the joiner does not stay the same size it is flexible to the indent.

          1. Sep 17, 2012


            I mean the thin line that joins selected value with annotation pane. It runs from selection to annotations but when we have multiple values in a row, the line that starts from the left ones will go through the columns to the right.

            That is, if value2 is selected in a table (the pencil icon clicked):

            value1 | value2 | value3 | value4

            The joiner must start from value2 and go right to annotations pane going over value3 and value4.

            1. Sep 18, 2012

              We need a phone/skype call

            2. Sep 18, 2012

              Also we need to first agree tha main aspects of the new layout.

              If the layout is 99% there and going to work for everyone but the only issue is a graphical line going from the data to the annotation pane then this is not a good reason to delay. if feels to me that there may be a number of ways to align the annotation pane with the fields. The details can be worked out once the main principle of the layout is agreed.

              1. Sep 18, 2012

                Well, the same graphical line was the reason we have spent a few days discussing and changing GUI so that it would be acceptible for BM. Please, refer to our mails on joiner. As I have said, I did not implement the line due to the same issue I am raising now.

                It seems that "99% there" did not serve us well previous time.

                1. Sep 18, 2012

                  It serves me fine and I have already had this same discussion with Vladimir when discussing the annotation pane scroll. I was fine losing it and was surprised when it was implemented. Again, I think it needs a phone call.

                  1. Sep 18, 2012

                    I could do a call Thurs am. In principle is everyone mainly happy with the design? Bar Janas issue with the joiner?

                    1. Sep 18, 2012

                      Can we all do a call at 10:00 uk time tomorrow?

  2. Sep 19, 2012

    I don't quite understand note 5 in latest mockup. What does "Block expands and changes color" mean?

    Unfortunately, I won't be able to make it tomorrow.

    1. Sep 19, 2012

      When would be a good time for the call?

      The block expands and changes colour refers to the interaction when the user selects that block by clicking on it. It needs to expand to fit in the menu items and changes colour to indicate it has been selected.

  3. Sep 19, 2012

    I am happy with either version 2 or 3 - Please select the easiest to implement. We dont need the connector as long as it is clear to the user and we can reset the annotation panve to align with the selected item. This is how other sites do it and I provide an example of this in the annotation scrolling links.

    Please provide Hollie with any other quastions for clarification for the design.


    I agree with Vladimir that the current priority is to sign off stage 3.4 and start 3.5 and do the data basket. I will arrange a meeting with Vladimir toconfirm final plan for 3.5.

    Jana - Please can you tell us what your current role is (are you fully back!) and what the lines of communication should be from this point onwards.


    Hope your maternity leave went well and that you and the baby are doing well. Cheers, D

    1. Sep 19, 2012

      I am still on maternity leave. I will be back in 2 weeks hopefully. I will discuss current progress and role/communication with Vlado.

      Please, regard my comments as notes for now. I am trying to keep in touch with RS but I am sure I have missed quite a lot.

      Baby is doing great. She grows so fast she might even help me on Stage 4. :)

  4. Oct 17, 2012

    On note 5: Field clicked to expand and reveal...

    How would this work for collapsed sections. Usually, clicking on the title would expand/collapse section.

    What about the selected AP (Documented In) in this case. They will have both the joiner and the yellow background? How is this going to look like exactly?