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 Improvements #170

Open
fenilgmehta opened this issue Mar 18, 2023 · 1 comment
Open

UI Improvements #170

fenilgmehta opened this issue Mar 18, 2023 · 1 comment

Comments

@fenilgmehta
Copy link

fenilgmehta commented Mar 18, 2023

Hi team, following are some places where UI can be improved to make things more intuitive

Case 1

When waiting for some action for a peer device
image

The clock icon could have a yellow color background like the below one so that it is more easily visible/noticeable to the eye
image

Case 2

When waiting for file acceptance - we can use blue background for the ✓ tick button as it is the preferred action
image

Case 3

Change A

When waiting for file acceptance and files would be overwritten - we can use red background for the ✓ tick button as it is a destructive and generally the preferred action
image

Change B

I think it would be nice to have Files may be overwritten message also in red to indicate that it is talking about a destructive thing and the color would also make it more noticeable (which is required since the transfer is blocked and waiting for the user to make a decision).
image

Case 4

Change A

image
If we observe the above image, generally the preferred action is on the left and the secondary action is on the right. To maintain that consistency, can we have the icons shown in the below case be switched (i.e. left should be open the containing folder, right should be remove this operation from the list). This change will also ensure that remove this operation from the list icon is always on the right hand side
image

Change B

Since open the containing folder is the preferred action, but not an action where warpinator is waiting for the user to approve file receiving/sending, we can have a light blue background (instead of a bright blue which is used in case 2 above) for the button

@mtwebster
Copy link
Member

Hi, these are some useful suggestions -

  1. Just to clarify, the clock icon is to mark 'recently visited', not pending action. If you have many machines in the list and select one further down, when you return to the overview, that machine will be at the top of the list with the recent mark. Machines are sorted from top to bottom: Favorites, recents, followed by the remaining machines (all three groups sorted alphabetically to themselves).

Also, we prefer symbolic icons in our applications now, with few exceptions - this makes it a lot easier to maintain readability with different themes as well as 'dark' versions of themes.

  1. I'll consider it - though I always considered this 'suggested action' style to be more appropriate when there was one and only one such action available (and usually it's the one you'd pick if you just hit enter). If you have multiple transfers pending, this becomes less useful I think. Still, worth considering.j

3a) This seems weird, I'm not so sure about it - it could mean some checks are red, some are green (or blue, depends on theme), and I don't agree it's destructive in a way that matters enough to do this, especially if...

3b) ... This is probably a good idea, and I think enough to warn the user about the potential overwrite. I need to add this warning to the desktop notification also, since transfers can be accepted directly from it.

4a) Good idea, though the order was like it is mainly so I can put all possible buttons in a row and just hide/show the appropriate ones. I'll have to see if I can work that out with an improved order.

4b) I'm not sure I want to go too crazy with the special button styles, and again, with multiple transfers, I think it could start to look cluttered.

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

2 participants