brainstorm on enhancing UX and UI

[marc-portier]

some ideas coming to mind:

• avoid duplicating the mapping config (now at bottom of the analyze tab and at top of unify tab)
• give quick dashboard linke insights on possible issues (e.g. based on track ingestion process for robustness and reporting of status / issues #29 )
  • on the overview page of all vocabs it would be good to give some health indication / highlight vocabs that need attention
  • add dashboard tab to each vocab with clear health/stats indications (how many entities / where in the pipe, how many searches, size and last update of index, .dates of last access/ingest/update, .. )
• avoid starting the obvious next step explicitely --> but do it automatically e.g.
  • when the ingest is done --> start the analysis
  • when saving the mapping config --> launch the unification
• support larger setups --> allow filtering, searching sorting in the list of vocabs
• allow reusing the mapping-config from another vocab (all skos-like bodc vocabs are essenjtially the same)

further ideas welcome at this stage / to further discuss - document and plan for

[marc-portier]

another idea:

• analysis result feedback should always show - even if counts are zero
  currently this screen:
  

leaves one to wonder -- analysis was ok apparently, but where is the result?

[marc-portier]

one more as a suggestion from #35

• when pressing the [DELETE] the end user should get a decent and immediate feedback to make clear the event / action got accepted at least --> this could be through (i) dimming the button, (ii) changing its caption to [deleting...], (iii) replacing the dialog text with a message about the delete-job being started and the possible time it will take, (iv) closing the dialog, or some smart combination of the above
• while a running delete job is known to be associated on a vocab, its listing should be dimmed in the list of vocabs, and no further actions should be possible on it -- at least for a reasonable timeout (~30 minutes acceptable?)

[marc-portier]

late idea to consider -- the UX of the real target result (being the actual widget) is also something we might want to discuss and consider -- motivation: its use of it should be manyfold the use of the admin pages -- thus the payback should be far bigger

ideas popping up:

• allow for self controlled selection/feedback and actual value-reading api
• allow for multivalue select too (eg similar to how the admin UI has now the property-path widget)