ui review

[dericed]

Starting this issue for discussion and mockups about reviewing the user interface of bwf metaedit, discussion and prioritization of any enhancements, etc.

[ablwr]

Hi, thanks for starting this issue, @dericed.

I gave this some thought and I have arranged my jumble of thoughts into three categories, from high-level to small bugs.

I know there's a budget for a BWF MetaEdit2 but also know that it's not too big, so I tried to break this up in ways where each can be made into individual tickets and managed, but some build off of each other (and a few may even be in contrast with others).

High level concerns

• MetaEdit suite of logos? It is confusing for the FADGI logo to be the icon used for this application. I heard that some people end up just calling the app itself "FADGI" instead of BWF MetaEdit. It'd be nice if all the MetaEdits had similar but different logos. I have something in mind but I will have to draft it up.
• Colors? It'd be nice to be more intentional about this, and allow the color choices to work with both light- and dark-mode. Colors are pretty rough on the eyes, especially "unsaved content neon green".
• Needs README This repository needs a top-level README just to point people in the right direction. The primary site is under MediaArea, but a lot of people land on this page first, too.
• Hierachy of information Archivists have to look at ugly spreadsheets all day so it'd be nice if this didn't look like a spreadsheet too. I think applying some hierarchy of information practices can break up the dry data and have it make more sense.

Design thoughts (medium-level)

• Grey text Text being grey is no good, even if meant to signify "you can't edit this" it's too grey. Could express this in a different way, or better yet draw the users attention to fields that do allow editing, without modifying text color. It'd be better to have the mouse change on hover to indicate clickability, and have it not change for uneditable items.
• View divisions This Core/Tech divide is weird/annoying. I think they can be combined. All of the information per record doesn't have to be on one row. I think it'd be better to have each file on three rows actually -- one for the filename and button that allows the record details to be collapsed, and two rows for the Core and Tech metadata fields.
• Toolbar Left toolbar doesn't do much that the top toolbar already does, except the save button, which...
• Save Save button is just mixed in with everything else. It should have more priority. The "Save" step is pretty significant step, and...
• Undo Can we get an "Undo" feature to undo the last step?
• Hidden features Right-click fill-all-files is an important feature but not as obvious as it should be.

Bugginess (small things)

• Values jump to fit width when user hits "Save"
• Headers should have small indicators that clicking them will sort them
• Not clear how to remove files, could do better than "Close all files" in the dropdown menu (if there is going to continue to be a left-hand toolbar)
• If you want to remove one file from a bunch you can't really do that, which is annoying. Would be good to be able to remove specific files instead of "all or nothing"
• While length should be appropriate (e.g. Description could be bigger), it doesn't make sense to expand the fields to their full length. Makes long fields difficult to read. Fields could be mapped to determine how long they generally are.
• Hover is unreliable -- doesn't appear unless an edit has been made to the row.
• Default open size of Help popout box is too long. Humans are comfortable reading lines that are shorter, this box could be 50% shorter.

[ablwr]

Also I would like to give a UI review to this issue, which is called I U review, but this is meant for general user interface design feedback, not Indiana University feedback (although they are welcome to give it).

[dericed]

Hi @ablwr, could you refresh these notes after the 20.08 release and prioritize a few issue to address for the next one?

[ablwr]

Here's an update -- I'll think about this a bit more and comment again on what we should consider for the next release!

High level concerns

• ✔ ~MetaEdit suite of logos? It is confusing for the FADGI logo to be the icon used for this application. I heard that some people end up just calling the app itself "FADGI" instead of BWF MetaEdit. It'd be nice if all the MetaEdits had similar but different logos. I have something in mind but I will have to draft it up.~
• ✔ ~Colors? It'd be nice to be more intentional about this, and allow the color choices to work with both light- and dark-mode. Colors are pretty rough on the eyes, especially "unsaved content neon green".~
• Needs README This repository needs a top-level README just to point people in the right direction. The primary site is under MediaArea, but a lot of people land on this page first, too.
• ✔ ~Hierachy of information Archivists have to look at ugly spreadsheets all day so it'd be nice if this didn't look like a spreadsheet too. I think applying some hierarchy of information practices can break up the dry data and have it make more sense.~

Design thoughts (medium-level)

• ✔ ~Grey text Text being grey is no good, even if meant to signify "you can't edit this" it's too grey. Could express this in a different way, or better yet draw the users attention to fields that do allow editing, without modifying text color. It'd be better to have the mouse change on hover to indicate clickability, and have it not change for uneditable items.~
• ✔ Solved with File View ~View divisions This Core/Tech divide is weird/annoying. I think they can be combined. All of the information per record doesn't have to be on one row. I think it'd be better to have each file on three rows actually -- one for the filename and button that allows the record details to be collapsed, and two rows for the Core and Tech metadata fields.~
• Toolbar Left toolbar doesn't do much that the top toolbar already does, except the save button, which...
• Save Save button is just mixed in with everything else. It should have more priority. The "Save" step is pretty significant step, and...
• ✔ ~Undo Can we get an "Undo" feature to undo the last step?~
• Hidden features Right-click fill-all-files is an important feature but not as obvious as it should be.

Bugginess (small things)

• ✔ ~Values jump to fit width when user hits "Save"~
• Headers should have small indicators that clicking them will sort them
• ✔ ~Not clear how to remove files, could do better than "Close all files" in the dropdown menu (if there is going to continue to be a left-hand toolbar)~
• ✔ ~If you want to remove one file from a bunch you can't really do that, which is annoying. Would be good to be able to remove specific files instead of "all or nothing"~
• ✔ ~While length should be appropriate (e.g. Description could be bigger), it doesn't make sense to expand the fields to their full length. Makes long fields difficult to read. Fields could be mapped to determine how long they generally are.~
• ✔ ~Hover is unreliable -- doesn't appear unless an edit has been made to the row.~
• Default open size of Help popout box is too long. Humans are comfortable reading lines that are shorter, this box could be 50% shorter.

[ablwr]

Quick fixes:

• Add README to base repository to direct people to appropriate places (MediaArea site, License, Contributing, Building, etc)
• Default open size of Help popout box should be ~50% shorter
• "Headers should have small indicators that clicking them will sort them" this appears after clicking, but can it appear by default for all?

The last bit is saving, which I think can use some rethinking. I think the file view can use a little bit of shaping up. I can file an issue about that.

Should I file an issue for these smaller things too? Then we can resolve this UI review issue.

[JeromeMartinez]

Should I file an issue for these smaller things too?

It is fine as is, @g-maxime will handle the remaining issues soon.

[ablwr]

More of these have been resolved, thank you!

Wondering about this one...

"Headers should have small indicators that clicking them will sort them" this appears after clicking, but can it appear by default for all?"?

[g-maxime]

"Headers should have small indicators that clicking them will sort them" this appears after clicking, but can it appear by default for all?"?

It's already the case but the indicator disappear when we add more files, should be fixed incidentally by #217