Talk:ViRR GUI
Jump to navigation
Jump to search
Release 2[edit]
Technical and functional suggestions for TOC Editing interface[edit]
Requirements
- UC_VR_ED_01 Edit structural content, including
-
- This requirement is not mentioned in the proposals. The idea is, that the user can edit the pagination independent from the creation of a toc. --Kristina 08:48, 9 September 2008 (UTC)
- UC_VR_ED_08_Edit_bibliographic_metadata is missing. --Kristina 07:35, 9 September 2008 (UTC)
GUI Proposal 1[edit]
- The screen is divided into 4 parts:
- Left part: Shows the TOC tree that is currently edited. Next to each tree branch the following commands are available: Add Child, Remove, Edit
- Is should also be possible to change the position of a child within the tree. --Kristina 07:35, 9 September 2008 (UTC)
- Middle part: Biggest part, shows the image of the currently selected page.
- User should have the possibility to decide if he wants to see the image on the current screen, on a second screen (separate window) or if he does not need the image because he has the real book in front of him. --Kristina 07:35, 9 September 2008 (UTC)
- Upper right part: Tree with flat book structure, means the root element is the book name, all pages are available under the root in a flat hierarchy (structure is retrieved from container)
- Does that mean that the user can edit the pagination here? --Kristina 07:35, 9 September 2008 (UTC)
- Lower right part: Provides fields for TOC properties (label, order number, order label, type, parent element)
- To my understanding thats the main working part. Shouldn't it be more prominent? --Kristina 07:35, 9 September 2008 (UTC)
- Implementation of Use Cases:
- Creation of structural element:
- The user selects the branch from the TOC tree to which a structural element should be added by selecting the "Add Child" command. A new, unnamed element is created and displayed in the TOC tree. Additionally, the left part can provide a link "Empty structural element" for creating elements that should not be linked to a certain page or book.
- It could also happen, that not a child element is needed but a sibling. --Kristina 07:35, 9 September 2008 (UTC)
- The user selects the page/book to which the new element should point from the upper right part. The page is shown in the middle part. If the user does not want to link the element to a certain page, the upper right part also provides the selection alternative "empty structural element".
- It should be possible also to link an element to a bundle of pages. --Kristina 08:48, 9 September 2008 (UTC)
- The user fills out the fields of the lower right part.
- The user clicks on "Save". The element in the toc tree is updated
- The user selects the branch from the TOC tree to which a structural element should be added by selecting the "Add Child" command. A new, unnamed element is created and displayed in the TOC tree. Additionally, the left part can provide a link "Empty structural element" for creating elements that should not be linked to a certain page or book.
- Editing of structural element:
- The user selects the element he wants to edit from the toc tree by clicking "Edit". The page to which this element points is displayed and the data of the toc element is shown in the lower-right part.
- The rest of the steps are the same as when creating a new structural element, steps 2-4.
- Deleting a structural content element:
- The user clicks the "Remove" command of the element in the TOC tree that he wants to delete. The element is removed and the tree is updated
- Editing pagination:
- The user clicks the "Edit" command of the desired element. He can change the pagination by manipulating the order field in the lower right part.
GUI Proposal 2[edit]
- Similar to proposal 1, but the screen is not split. The TOC is shown on a separate page with the same commands. The TOC property fields and the flat page tree are on another page.
- So you mean three pages (one for the toc, one for the image and one for the flat tree together with the property fields)? --Kristina 08:48, 9 September 2008 (UTC)
- Implementation of Use Cases:
- Similar to Proposal 1, but on separated pages. When clicking the "Add child" or "Edit" command of the TOC tree, a new page is loaded that shows the TOC property fields and the flat page tree. After clicking "Save", the changes are updated and the TOC tree is displayed again.
- Sounds not very user friendly. --Kristina 08:48, 9 September 2008 (UTC)
GUI Proposal 3[edit]
Slightly modified version of GUI proposal 1
- starting from creation of a new Toc object, proposal to split the creation / editing of the TOC into 2 steps (not necessarily 2 GUI screens):
- Assumption: container for which user creates the TOC object is always pre-selected
- I think its a good idea, that the user can separate between the creation and the editing of an toc element, but must not. --Kristina 08:48, 9 September 2008 (UTC)
- Step 1
- user defines the main structural TOC elements in a kind of hierarchical structure: Book->Chapter->Page or Book->Chapter, Appendix->Page (note: some information on these can be stored in the content-model specific properties of the container)
- user finalizes this step and system creates TOC object
- user has direct links to create exact node-type (i.e. add Book, add Chapter) depending on currently selection in the TocNodes
- on the side of the container tree, user is able to directly add the node to the newly created node (i.e. has link AddToToc - the system would know that the currently created node on TOC side of the screen is e.g. Chapter).
- user would be able to make multiple selections in following manner:
- has option to select range of IDs (gives the first ID and the last ID for the range from the container tree) and add them directly as e.g. Pages in the selected Chapter node of the TOC
- empty node (i.e. not related to data object should still be possible)
- GUI component functionality needed
- Mandatory
- tree-table
- selectable nodes
- collapse/expand
- Optional
- editable tree-table
- multiselect (or range select)
- move up/down
- drag/drop
- more detailed sketches with Markus--Natasa 12:30, 4 September 2008 (UTC)
Additional Ideas[edit]
- Manipulating the Toc tree via Drag'n'Drop (That would be very nice. --Kristina 08:48, 9 September 2008 (UTC))
- Problem: The currently used JSF libraries (Apache MyFaces Trinidad) do not support drag and drop mechanisms. If this is a mandatory requirement, I see two alternatives here: Implementation as Java Applet or use of new libraries, e.g. RichFaces.
Release 1[edit]
Internal Meeting 01.07.2008[edit]
Participants: Rupert, Natasa, Wilhelm, Markus M., Kristina
Discussion on ToC
- The ToC of a volume on the interfaces is part of R2, not R1.
- The additional layer right to the detailed view of a picture presenting a ToC with access to different levels is proposed in the FPT but not requested by the MPI. Additionally the implementation effort is regarded as to high/unknown to be scheduled for R2. Proposal by Dev and SvM is to keep it as an idea but not implement it till we know more about the coming functionalities of ViRR especially about the display of transcriptions (which are used to be also displayed next to the detailed view of a picture).Further on, as a ToC can have many hierarchy levels its not clearly specified how they might appear within the layer.
- Decided (by Malte)
- The first priority is the TOC implementation on the separate page and enabling it in addition for DFG viewer
- Same level priority is also to make experience with layering (show/hide additional data) on presentation on detailed image page: it is therefore agreed to make this experience with the metadata display of the image and not with the navigational part (i.e. TOC repetition)
- Navigational part: is optional for R1 (depending on time) and in meantime GUI team would in details specify how it should behave when user navigates to an image via GoTo or Karusel. Also, vice versa, how it should behave when user navigates through the tree and makes a selection (images are uploaded, karusel is "rewind" to appropriate pos. etc.). GUI team would also specify exactly how the current level (to which current image on the page belongs) will be displayed (Malte's proposal: same as in Windows explorer) - note: space and padding should be considered carefully as there may be many levels.
- In meantime, GUI team would also take a look at functionalities for Transcriptions and try to have this in mind before actual start of the implementation of navigation tree in detailed view.
- Decided (by Malte)
- An additional button "open/close all hierarchy levels" will be included in the ToC of the page "Band".
Postponed for R2
Due to missing metadata of the ToCs the following elements/requirements are postponed for R2:
- The "go to" box will be based on physical page numbers, not on logical ones. To let the user know which physical page numbers are available, a list with the physical page numbers next to the logical ones (numeration) is needed.
FPT is approved insofar as implementation can start
Feedback on the Prototype[edit]
Still to do:
- Formatting of the remain of the ToC
- Icon for the metadata view
- Adaptation of the logo (based on the eSciDoc.Faces logo)
Rupert: Done --Rupert 13:58, 13 June 2008 (UTC)
Feedback from Ulla:
viel "runder" als der erste wurf aus meiner sicht;-)
just some details:
- page Metadata Mehrbandwerk: es fehlt die Jahrangabe in der kompletten Referenz (würde ich nur hinzufuegen, weil es dem institut sehr wichtig ist, wo welche Metadata stehen)
Die Jahreszahl habe ich schon mal ergänzt.--Rupert 22:50, 1 June 2008 (CEST)
- Detailansicht mit/ohne Header: nur zum verstaendnis: sind das aus unserer sicht vorschlaege (ie.institutsentscheidung) oder gibt es dabei irgendwelche technischen hintergruende oder pattern gruende?
Rupert: Es ist ein Vorschlag für das Institut, da unsere Header immer recht groß sind. --Rupert 09:42, 2 June 2008 (CEST)
- Detailansicht erweitert
- die erweiterung auf der linken seite muesste scrollbar sein dachte ich...?
Rupert: Der Scrollbalken erscheint immer dann, wenn der Inhalt nicht mehr in den layer passt. Das ist in Axure nur angedeutet. --Rupert 09:42, 2 June 2008 (CEST)
- bisschen verwirrend imho fuer nutzer, weil a) erweiterung links und b) link/icon zu "metadata" (unter dem link zu "vollbild") zwar gleichen content bieten, aber nicht zur gleichen seite fuehren. der unterschied der beiden "sichten"/"sichten" ist nicht auf anhieb klar. Vorschlag: wenn man links die erweiterung "context-sensitiv" machen koennte, ie. wenn ich aufklappe, springt das system an die stelle des toc, wo ich gerade bin, koennte man den alternativen zugang ueber MD (ie komplette Md seite mit toc) vielleicht besser abgrenzen.ist aber nur idee...--Ulla 17:25, 20 May 2008 (CEST)
Rupert: Kontextsensitiv macht Sinn, da ich ja über die blauen Links in das Kapitel führen und sich die Detailansicht anpasst. Umgekehrt sollte natürlich auch ein Blättern mit den Pfeilen auch die Kapitelauswahl aktualisieren. Die Kapitelangaben sind aber zunächst mal nur exemplarisch drin, um ein Gefühl dafür zu vermitteln ob der Platz reicht. Für R1 ist noch gar kein Navigieren über ToC vorgesehen. --Rupert 09:42, 2 June 2008 (CEST)
Feedback from Malte:
ein paar kurze Anmerkungen...
Insgesamt scheint mir der Pageflow nun sehr viel guenstiger und intuitiver..
Einige Sachen scheinen mir aber noch nicht rund...
- statt links "+/-" sollte es besser "hide-show" heissen..
Rupert: Dann müsste es hier Einblenden-Ausblenden heissen. Selbst wenn man nur einen Begriff verwendet (Toggle) wäre es sehr raumgreifend und der breitere layer sieht dann einfach leer aus. Wäre es auch ok die Funktion mit einem TITLE tag zu versehen?
- der selbe mechanismus fuer den bereich oben wird nicht klar, wenn das bedienelement rechts neben funktionen liegt.. hier sollte das element zum auf-/zuklappen woanders liegen oder anders kenntlich gemacht werden..
Rupert: Eine ähnliche Funktion ist gerade für FACES im Entwurf, die werde ich noch einbauen.
- in der zusammenfassung eines bandes sollte das browsen zu den bildern nicht nur ueber die titelseite geschehen, sondern auch ueber eine textlichen link an prominenter stelle im hauptkasten.
- ebenso sollte klarer werden, dass in diesem hauptkasten ein klick auf den titel des multi-volumes nicht auf die scans, sondern zurueck auf die metadaten zum volume/multivolum fuehrt.
- auch nicht so ganz wichtig.. aber die direkte eingabe einer seitenzahl ist optisch noch nicht so gut integriert und wirkt etwas losgeloest..
Feedback from Natasa:--Natasa 13:19, 13 June 2008 (UTC)
- Metadata icon on the detailed view should not lead back to the "Band page overview" but to the metadata of the page item actually
- reasoning: Natasa expected metadata on image and not going back to the Band page overview
- Rupert: I would wait for institutes opinion on navigating Mulitvolume Metadata, Volume Metadata, Detail view.--Rupert 14:10, 13 June 2008 (UTC)
- At the moment there isn't any metadata available for an image, only for the whole book. But perhaps the Metadata icon is misleading and should clearly display that it means the metadata of the book. --Kristina 06:52, 16 June 2008 (UTC)
- Perhaps it's a misunderstanding: metadata are defined on book level, but each page has again metadata record. In addition it saves some image info such as: order, page label .. pls. check for more details with Wilhelm. --Natasa 07:43, 16 June 2008 (UTC)
- question raised: if user is on page 100 and clicks on Metadata - and goes back to Band page overview - should user have possibility to go back again to the image page he just left? (technical issue as we have to maintain a lot of session information)
- Rupert: For first step the page number does not need to be kept. If they go for the proposed layer in detail view, they do not need to leave the page. If not we need to care for the page number.--Rupert 14:10, 13 June 2008 (UTC)
- If needed add separate link to the "Band page overview"
- Maybe is nice to have also a possiblity to view the "technical metadata" of the image (in addition to descriptive metadata)
- eg. descriptive metadata of page image: material (i.e. in case of cover pages = leder), size , page number (physical, logical) etc. , content-category (e.g. cover page, title page, chapter title page, content-page etc.)
- eg. technical metadata: device metadata, resolution, format etc.
- Rupert: To be discussed for next prototype how to separate or display together: Technical Metadata (Volume Level), Descriptive Metadata on Volume Level + Multivolume Level --Rupert 14:10, 13 June 2008 (UTC)
- The display of technical metadata is not part of the scope for R1.--Kristina 06:52, 16 June 2008 (UTC)
Internal Meeting 07.05.2008[edit]
Participants: Rupert, Ulla, Kristina
GUI TODOs[edit]
- Using of consistent terminologie
- Mulktivolume = Mehrbandwerk
- Volume = Band
- General
- Page can not be named "Metadata" or "Detailansicht"; the headline should have content in it (e.g. the short metadata of the volume)
- Page"Metadaten Buch" (in Axure)
- Page has to be structured new and nicely
- Thumbnail should be bigger, so that the user can see alt least something
- The ToC has th be formated nicely
- The display of the icons should be consistent
Internal Meeting 25.04.2008[edit]
Participants: Malte, Natasa, Wilhelm, Rupert, Andi, Kristina
GUI TODOs[edit]
- Consider two different views of metadata, one for the metadata of a multivolume and one for a volume
- Page Elements
- 1. Multivolume Information (bibliographic metadata)
- 2. List of Volumes
- 3. Volume Information (bibliographic metadata)
- 4. Chapter List (structural metadata)
- 5. Thumbnail (d001)
- 6. Picture
- 7. Detailed Title
- Page1: Browsing Tree
- Page2: Overview Multivolume (with page elements 1+2)
- Page3: Overview Volume (with page elements 1+3+4+5)
- Page4: Detailed View (with page elements 6+7)
- Click on extra link in the detailed view should open the biggest jpg itself in a new browser window
- New icon for the Detailed View is needed (instead of the thumbnail)
- Header area should be more condensed for detail view to display more of the picture on the screen
- Our proposal for the alternative display of metadata on the detailed view is the moving layer on the left side (the other proposals will be deleted from the prototype)