Made changes to mock UI following discussion with Dr. Loraine.

Tested on additional user (BK). In general, they found it to be intuitive and easy to use. Primary comment was to have mouse-over tooltips for buttons and attributes. Some confusion in New menu regarding the upload quickload option - wasn't sure if needed to upload a quickload to make a new quickload. Did not know what to expect in terms of downloading a quickload (such as what would be included). Unclear what the undo/redo buttons would do. The +New button worked well and was intuitive.

Closing issue.

Some notes after meeting with Dr. Loraine:

May be worth having an example Quickload in the left panel for a new user to see/explore. This way they can see how a Quickload can be structured, what kinds of data/urls/names go in each field, etc.

Do not need to show that changes have been saved. Instead, give user a warning if they are disconnected from server. The default assumption should be that everything they change is automatically saved.

The publish/cancel buttons have been removed. In terms of implementation, everything should be in the database, and the various files needed (contents.txt, annots.xml) would be generated on demand by the server. So as soon as a change is made in the Quickload Builder it is saved and available to IGB.

Do not provide/allow default folder/file names. Users have to enter something.

Consider allowing users a way to bulk upload information. A scenario would be a user with a file containing a column of file names and a column of their respective URLs. We would parse the file and create files containing that information. That way a user with hundreds of files could quickly generate all of them. Another example would be to allow users to upload a quickload. They may have already made a quickload manually, or someone provided them with one. They would upload it, we would parse it, and display the quickload in the quickload builder. We could then provide "example" quickload structures for users to try out.

For file properties, we will need to change the attribute names to be more clear. For example, the name attribute is the url to the file, whereas the title is whatever name the user wants the file to show up as in the quickload. Name should be changed to URL/link, and title to name. All of the attributes will need to have tooltip descriptions.

After discussing further edge cases, I think the easiest/best way to move forward with implementing the UI to look like the IGB Available Data would be to limit each Quickload to a single genome.

Adding mock ui version 2 as per Dr. Loraine's suggestions.

Dr. Nowlan Freese,
I have uploaded the mock UI in Shared folder. Please review the same.