Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ui review #73

Open
dericed opened this issue Jan 8, 2020 · 8 comments
Open

ui review #73

dericed opened this issue Jan 8, 2020 · 8 comments
Assignees

Comments

@dericed
Copy link
Collaborator

dericed commented Jan 8, 2020

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

@ablwr
Copy link
Member

ablwr commented Jan 8, 2020

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
Copy link
Member

ablwr commented Jan 8, 2020

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 dericed mentioned this issue Jan 26, 2020
@dericed dericed changed the title iu review ui review Aug 12, 2020
@dericed
Copy link
Collaborator Author

dericed commented Aug 12, 2020

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

@ablwr
Copy link
Member

ablwr commented Aug 14, 2020

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
Copy link
Member

ablwr commented Aug 14, 2020

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
Copy link
Member

Should I file an issue for these smaller things too?

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

@ablwr
Copy link
Member

ablwr commented Sep 30, 2020

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
Copy link
Contributor

g-maxime commented Jun 7, 2021

"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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants