ViRR GUI

ViRR,MPDL,FIZ

= Release 3= Outcome moved to Meeting Page.

= Release 2.6 =
 * Problem: Hierarchieebene des markierten Eintrags nicht ersichtlich farbliche Kennzeichnung/Verdeutlichung erforderlich
 * Colors not possible (discussion with Malte). Proposal see screenshot.



= Release 2.5 = Rework of Volume entrance page

= Release 2 =

Internal GUI/DEV Meeting, 16.03.09
PARTICIPANTS: Rike, Markus M., Wilhelm, Markus H., Rupert

Schedule:
 * 1) DEV is working in parallel with Markus M. in two steps: First available parts of Wilhelms development is taken into GUI Implementation and then Markus H. components. Most effort is necessary for JS implementation of image magnifier and the dynamic layout.
 * 1) The April schedule can be met if no bigger effort is necessary for FACES bugfixing (browser compatibility).

Issues:
 * 1) As GUI V2 is still not yet used for ViRR R2 it will not meet requirements of GUI Accessibility and GUI Constraints fully.
 * 2) The ViRR functionality should be accessible for FF2, FF3, IE6+7. Limitations in layout consistency will be the case.
 * 3) The word-functionality "Gliederungsebenen" is still problematic from technical point of view (dropdown ebene 1-x) because it can not easily solved to feed the dropdown with available levels in advance.

Internal Meeting, 20.01.09
PARTICIPANTS: Natasa, Ulla, Rike, Markus M., Wilhelm, Kristina


 * 1) Page "Detailansicht" and "Paginierung und Struktur"
 * 2) * As required from the institute, all metadata about a structural element will be displayed in the browsing tree. We will wait for a specification of the institute till Fr. 23.01.09. When they won't deliver a proposal, I will make one to the GUI the following week.
 * The tree would simply look extended with Label/Value pairs below structural element. --Rupert 09:56, 27 January 2009 (UTC)
 * As discussed today with Rupert and Malte, we will implement the editing tree as primary proposed by the GUI. The desired detailed view with all metadata in the tree (similar to the eBind editor) will be provided as a new function "preview" in a separate window. This will be implemented in R3, not R2. --Kristina 13:08, 28 January 2009 (UTC)
 * 1) Page "Metadaten eingeblendet"
 * The problem with the drop down menu for the metadata fields is that currently validation roles are needed to make sure, that some metadata will only be used once. As that is very complicated, the drop down menu shall not be implemented. Alternative ideas are:
 * to have an metadata editing form with all metadata fields displayed in a separate window or layer
 * to have an metadata editing form with all metadata fields displayed in the already available frame with a scowl down functionality
 * First approach is this option with all Metadata in. Grouping is done later if necessary --Rupert 09:56, 27 January 2009 (UTC)
 * to have an metadata editing form with all metadata fields displayed in separate tabs in the already available frame
 * --> Decision lies by the GUI team
 * 1) Editor
 * 2) "Ebene 0-1 zeigen"
 * 3) * As meaning was not clear to all, please remove Ebene 0 and Start with Ebene 1 (because 0 does not exist)
 * 4) * Please rename "zeigen" in "aufklappen"
 * 5) Following buttons should be disabled when no page or structural element is selected or the functionality is not possible (please put the specification in the prototype)
 * 6) * "Anlegen"
 * 7) * "Löschen"
 * 8) * "Pfeile für das verschieben eines Elements"
 * 9) The button "Zuweisen" should only be enabeled when pages are selected
 * 10) Please integrate the link to the specification of the "Pfeile für das verschieben eines Elements" in CoLab in the prototype
 * 11) It's unclear where in the tree structur, a new element will be created when pushing "Anlegen". Please specify that in the Prototype.
 * 12) * An idea was to let the user select if the new element should be a child or a sibling of a selected element (e.g. via a context right click menu; Markus M. will check if that could be feasible)
 * The right click is not introduced yet. All elements should be created on the same level for now. So it does not need to be checked. --Rupert 09:19, 26 January 2009 (UTC)
 * Sorry, all elements as childs (see prototype notes). --Rupert 13:40, 28 January 2009 (UTC)
 * 1) Drop Down "paginierung"
 * 2) * Please rename "Alle auf dieser Seite" to "Alle angezeigten"
 * Should be kept in sync with PubMan. --Rupert 09:19, 26 January 2009 (UTC)
 * But we don't have "Seiten" in the scowl down menu (in PubMan we have), so the wording is really confusing. --Kristina 10:43, 26 January 2009 (UTC)
 * 1) All three frames of the editor do NOT work synchronous, because that can create several problems. Please integrate that point in the prototype.
 * OK, so ViRR will be different.--Rupert 09:56, 27 January 2009 (UTC)
 * 1) An idea was to distinguish the browsing frame (the left one) from the editing frames (the one in the middle and the right one) via the usage of different colors
 * A color was already discussed and discarded. --Rupert 09:56, 27 January 2009 (UTC)
 * 1) Button "Zurücksetzen" is technical really complicated an will therefore be deleted
 * 2) Page "Inhaltsübersicht editor"
 * 3) * Please specify what will happen when the user chooses to use a filter (to my understanding, the multivolume has always be visible )
 * The filter was a proposal by GUI and not specified functionally yet. If it is required it needs to be specified from the functional point of view. --Rupert 09:28, 26 January 2009 (UTC)
 * It is required. And the functional specification is already there (see UC_VR_BD_08 View editors workspace. But the GUI specification is missing. The question is: how will the editors workscpace will be displayed when selecting an filter (because the problem is, that you have multivolumes displayed, which have no state. So will they be displayed when selecting a state, too (that would be useful) or not. That information has to be written somewhere in the prototype. --Kristina 10:43, 26 January 2009 (UTC)
 * Is a issue of the logic --Rupert 09:56, 27 January 2009 (UTC)
 * 1) Please use a consistent German wording (e.g. sometimes you use "Multivolume", sometimes "Mehrbandwerk")

Handover Meeting GUI to dev, 17.10.08
PARTICIPANTS: Julia, Kristina, Rike, Markus M., Markus H., Rupert, Wilhelm

Editors Workspace:
 * There are three conditions a volume/multivolume can have from the user point of view (not item status)
 * 1) No ToC ("Kein Inhaltsverzeichnis vorhanden")
 * 2) In Work ("In Bearbeitung")
 * 3) Released ("Veröffentlicht")
 * There is no difference between "Edit" and "Modify"; further on only "Edit" is used to work on the pagination/structure
 * H1 in editor is called "Editor" not "Inhaltsverzeichnis" --> Opens the editors workspace
 * The scan is displayed in web resolution (has to be checked if zoom in function is still working properly)
 * It shall be possible to filter within the list, but not to sort it
 * If the list is filtered by status, all volumes not matching the filter are grey

Bibliographic Metadata:
 * Bibliographic metadata of volume (as part of a multivolume) inherit there metadata from multivolume. If the user decides to change the bibliographic metadata of the volume, it can be done optionally volume by volume.
 * Bibliographic metadata will be edited separately from the rest of the structural content of the book.
 * Bibliographic Metadata/Form. Title is part of the form and the form is pre-filled with values.

Editing Interface:
 * "Reset structure" is not feasible for pagination and structure as well. "reset structure" is therefore placed on top besides save.
 * Option "bis ende" is added to selection options (bis Buchende)
 * When creating a structural element, the type of the element will be displayed in the tree. After adding a title to the structural element, the beginning of a title cropped to word boundaries after 20 characters will be displayed in the tree, too (Type: Title).
 * The full title is displayed in a tooltip.
 * "Zuweisen" <-> New wording, because currently it is used twice for different actions.
 * The type of a structural element should be editable within the metadata section below the tree.
 * One button save is for saving all data and button release next to it releases the structural content.

Tree Behavior:
 * One page plus link (due to logic dependencies) is difficult to develop with trinidad: A function to show the tree with pages/without pages should be used.
 * When adding a new structural element, this element is marked. All elements are added to the same hierarchy level as the marked element.
 * +/- will be available for each level of the tree
 * When deleting one structural element, all input below this structural element will be deleted, too.

ToDo:
 * Page moving and tree behavior will be documented in page note (Rike)
 * A convention for moving pages and structural elements across hierarchy boundaries will be documented by Rike
 * Page notes will be included in FPT

General Requirements

 * For working with hierarchies, tree structures should be used, which can be opened/closed one by one or via batch operations for a whole level or the whole tree. By default always all hierarchy levels should be open.
 * When working with tree structures, all hierarchy levels should be able to be opened or closed via plus/minus without jumping back to the top of the page.
 * The different hierarchy levels of the structure of a book should be displayed well arranged.
 * The "go to page" functionality should include a list with all available pages, where the logical and the physical pagination will be displayed next to each other.
 * Editing:
 * All functionality of the editing interface should be performed via the mouse or the keyboard
 * When working with several frames: The individual creation of the frame size and position should be saved for each user.
 * A preview of the created table of contents should always be parallel available to the editing interface so that the user always sees what he has done.

'''The Name of the institute should be displayed on every page. A special corporate design is not needed.'''

Editing interface
Output from the telephone call on 19.08.08 with Frau Fritz, Rupert, Rieke and Kristina
 * Idea: Separation of the user interface on two parts (it should be possible to display this two parts in one browser window or in two when working with two monitors):
 * Editing area
 * Viewing area
 * The viewing area should support different functionalities
 * Thumbnail view of the scans of a book to get an overview (e.g. where are empty pages, where are illustrations).
 * Page view to see exactly one page
 * Zoom functionality to read also the smallest text

Output from the telephone call on 30.09.08 with Frau Fritz, Rupert, Rieke and Kristina
 * Changes in the GUI
 * Page assignment:
 * Only the start page should be assigned to a structural element (which indicates automatically, that all following pages belong to the same structural element till there is another start page assigned).
 * Pages should not be displayed in the ToC tree.
 * A QA of the created ToC is needed (a separate step between the editing and the release, which displays the whole tree with all associated pages).
 * Each hierarchy in the ToC tree shall be displayed in a different color so that the user always sees, where he is.
 * 1 = gelb
 * 2 = rot
 * 3 = hellblau
 * 4 = hellgrün
 * 5 = orange
 * 6 = lila (hell)
 * 7 = grau
 * 8 = braun
 * 9 = dunkelgrün
 * 10 = dunkelblau
 * Es ist nicht nötig, den Text selbst in dieser Farbe darzustellen oder farblich zu hinterlegen. Ein Kontrollkästchen irgendwo in der Ecke, das die Farbe/Ebene der aktuellen Position anzeigt, ist völlig ausreichend.
 * Drop down menu for the type of the structural element
 * Should contain an auto suggest
 * Should be sorted a following: First the basic elements (alphabetically, but with "Andere" at the end) then a small break and then the list with the enhanced structural element types (see values in the list of structural elements).

= Release 1 =

General Requirements

 * The ViRR solution has to be in German, because the content is German. Later on, an additionally English version can be implemented.
 * The English translation for "MPI für europäische Rechtsgeschichte" is "MPI for European Legal History" (has to be changed in the header of ViRR)
 * The entrance to the collection should be similar to a first look of a bookshelf.
 * For each work a browsing functionality is available which allows to browse within all scans/pages associated to the work (thumbnail lists are not useful, because the content of ViRR is mostly text (no graphics) and not visible in the thumbnails).
 * The bibliographic metadata of one book should be displayed next to the detailed view of each page of the book.
 * A combination of two scans in one view (like in a real book) is not required.
 * When viewing one page, the information (bibliographic metadata) about the corresponding book is interesting, but not about the current division. This should only be visible after a special action.

Structure of Pages

 * 1) Browsing Tree
 * 2) * Only multivolumes and volumes are part of the tree (nothing more like chapters etc.)
 * 3) * Multivolumes can be expanded
 * 4) * The entry for each volume and multivolume are the metadata in the medium view (as long as no medium view is available, we will use the short view)
 * 5) * The user has to select one volume in the tree --> The metadata view of the volume will be displayed
 * 6) Metadata View of one volume
 * 7) * All metadata of the volume and its multivolume will be displayed.
 * The local signature of the institute has to be displayed, but no further internal IDs.
 * 1) * The metadata should be displayed in a bibliographic format so that the user can reuse the metadata via drag and drop.
 * 2) * All structural information (with linking to the scans) available for the volume will be displayed
 * 3) * A Thumbnail of the Title page of the book (d1) will be displayed as beautification (this thumbnail will be linked to the scan of the same page)
 * 4) Detailed View of one scan
 * 5) Standard
 * 6) * The start page of a book is always d1 (the first page with script) not the cover
 * 7) * On the top op the page, the metadata of the volume has to be displayed in the short view (as header and orientation).
 * 8) Extended
 * 9) * The metadata (lightly reduced) from the Metadata View will be displayed in a frame on the left side of the Detailed View, which can be expanded or folded by the user based on his requirements. When this frame is expanded, the scan on the right side will be reduced so that it will be still displayed in a whole (without scrawling)

User Goals
The functional Prototype for R1 should enable the following user goals:
 * 1) User wants to get an overview on the digital content
 * 2) User wants to browse within a multivolume work
 * 3) User wants to browse one volume in detail
 * 4) User wants to go to certain page within one volume (i.e. logical page)
 * 5) User wants to view the back cover of a volume
 * 6) User is not satisfied with selected volume and wants to switch to another volume
 * 7) User is not satisfied with selected multivolume and wants to switch to another multivolume

= Prototypes = See VIRR Prototypes

= Closed discussions =

Quality correction of the pictures

 * The black frames should be minimized from the jpgs (Rupert)
 * Will not be done for all pictures, because it can only be done manually and that takes to much time. --Kristina 09:47, 3 June 2009 (UTC)


 * The jpgs will be newly created as jpeg 2000
 * Technical: Digilib can handle jpeg 2000 (as tested by Tobias). --Kristina 14:14, 28 August 2008 (UTC)
 * Currently there is no native browser support for jpg 2000 (needs a plugin); alternatively via download. --Rupert 11:39, 23 July 2008 (UTC)
 * Who will provide those images and when? --Wilhelm 16:57, 29 July 2008

--> As jpeg 2000 will not be native supported by the available browsers, we will not create jpeg 200 at the moment. --Kristina 16:38, 28 January 2009 (UTC)