Version 1 by Vladimir Alexiev
on Aug 30, 2012 13:07.

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (31)

View Page History

h1. Compact Display

RS currently uses [RForms] to display object data.
- This was created by Jana in Jan-12, then refined in May-12 (without a mockup).
-- 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).

h2. 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
{noformat}
- *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 |
| 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 |
| 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:
{noformat}Material: gold, silver, wood.{noformat}
- RForms does not support Images out of the box. We added images.

h2. 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 (*y) 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

h2. 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.

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.

h1. Hollie's First Mockup

[https://svn.ontotext.com/svn/researchspace/trunk/researchspacetemplates-head/export/annotative-area.html]
Vlado: it has various problems, see red pencil:
- (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

h1. Fully Hierarchical Display

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:

- 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]
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 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 {jira: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.

h2. 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.
- 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|http://www.cidoc-crm.org/docs/epitafios5.0.1.htm], I leave it to you to decide whether you like it:
!data-hierarchical-XSL.png!

h1. Mockup V3

Attached is a new mockup. It shows tabular set up and also lists as requested by Jana and Vladimir.

I've amarked these up here : http://mocku.ps/txnvqi

I use chrome to view it, you can switch annotations on and off using a button at the top right corner.  !data.jpg|border=1!