Suggestion by Onto
It makes sense to use same design and implementation as for annotations tags. Currently these are stored entirely in Nuxeo and not in RDF. We suggest that in 3.6 we spend some effort on removing Nuxeo dependencies for annotations, including the tags functionality. Then we can use the same approach and implementation for Data Basket tags.
Dominic (with Jana on Skype, Oct 15): Lets have tags implementation reworked in 3.6 - that is, store tags in RDF and not Nuxeo. Then we will use common implementation for annotations and for data basket.
If items become too many, GUI might get unfriendly.
Dominic (with Jana on Skype, Oct 15): Lets keep it simple (no pagination) for now and see how users are going to use it. That is, are they going to use Data Basket as Clipboard (probably need to remove oldest items then) or as personal storage (more permanent thing).
The spec says data field can be added. What about predicates (like was-created-by)?
Dominic (with Jana on Skype, Oct 15): Will think about it but I cannot think of case they would need to store a predicate there.
“Data Field” should look the same as “Data Annotation” minus the pencil
If you vary the color between “Image” and “Image Annotation”, I think there should be the same variation between the above pair
there’s no “Data object”. There’s “Object” and that’s a museum object, so I don’t like the icon that looks like a table.
what’s “Forum”: link to a Forum Comment, which will be done in 3.6? Let’s rename to “Forum Comment”
Notes> Last updated: please remove, no such data has been discussed
Tags: We suggest these are specified separately and same design/implementation is used as in Annotations
The action name should be consistent with the item type. Either "Text" or “Text Snippet”
Button "Add text": should be consistent with the item type
We need fields for the long (to be entered) and short (to be calculated) links
You have buttons Edit/Save on top and bottom; also X on top and often Cancel on bottom. Do we really need double controls?
What's the action arrow next to Notes for?
Rich Text Editor: do you know such actual editor? Looks qquite better than the one with centered buttons that we currently use
- all data fields/data annotations are followed by two buttons - pencil and dropdown menu for custom actions (annotative-area.html). There is not enough space for both of them (e.g. tabular data like dimensions: width + 2 buttons + value + 2 buttons + measure unit + 2 buttons)
- inconsistent labels (databasket-edit-details.html) Data author/Data date -> data creator/data created
- do we need dropdown menu on the upper right corner of databasket-add-weblink.html/databasket-add-text.html/databasket-edit-details.html?
- do we need 'save' button on the upper right corner of databasket-add-weblink.html/databasket-add-text.html/databasket-edit-details.html? There are 'cancel' and 'save' on the bottom right corner!
- click on a row in databasket-popup.html will open databasket-detail.html/databasket-edit-details.html and it will be second level of popups (first one is the databasket popup and above it will be details popup). it is not very user-friendly
- do we need bookmarks for data field and data annotation? If user creates bookmark for data field and then he/she adds annotation for that data field, it becomes data annotation and automatically the bookmark should become bookmark for data annotation. We can use one bookmark type for both of them. Jana: field and annotation are 2 different things
- do we need bookmarks for image and image annotation? Both types will be opened in the image annotation tool! Jana: Different parts of the page will be highlighted though
- new button for bookmarks will be added in tinyMCE (rich text editor) but there are two more 'insert link to image', 'insert link to museum object'. Do we have to remove them?
- popup from databasket-popup.html is very big! We have to think of a solution that is smaller than the browser size (monitor resolution)
- header data in databasket.html is aligned left but header data in databasket-popup.html is aligned center and the whole table is not looking very good. (#page is inherited)
- all databacket table columns have width - isn't it better to remove widths and rely on browser formatting (e.g. if the databasket popup width is not very bit the whole table in it won't look fine)
- rich-text editor that we use is tiny MCE and it uses new browser windows for popups. Are we doing to implement databasket popup like this or it will be part of the page as a simple div tag? If it is new browser window - styling should be changed (there are minimum width of 1200 pixel for the popup, margin for the whole databasket table and so on). If it is part of the page as div it will look a little inconsistent with the other buttons of the tiny MCE. Still, we suggest we keep it as div.
- which will be the data basket sort criterias? We suggest type, date (default), title. The sort is by a single field
- Icons for data basket element types are way more than tool history (https://confluence.ontotext.com/download/attachments/26187321/RS_dataicons.jpg?version=2&modificationDate=1345207775000 and tool history has only 3 items). If one of the used bookmarks from databasket is selected then new history element will be inserted in one of the three history options. They have similar images as databasket icons and it may be confusing if data field/data annotation and museum object bookmarks will be added as an element in data annotation tool.
If the user selects an item to add in the databasket, and such item is already there, how do we inform the user?
If the user selects an item to add in the databasket, and such item is already existing there, then our proposal is: to be opened the "Edit details" pop-up screen, with the details of the existing item and a message for the user "This item already exists in the Data Basket". Where do you propose this message to be positioned on the screen? Or it could be another pop-up message?.