UI Improvement Suggestions #74

New Issue

2013-03-26T19:12:27+01:00

ghost commented

2013-03-26 19:12:27 +01:00

(Migrated from github.com)

Permanent tray icon
Notification pop-ups from tray when message received when window is not in focus
Switch to 'Send' tab when selecting 'Send message to this address' from 'Address book' tab
Capitalise the 'b' in 'book' on the 'Address book' tab (or drop the upper-case 'S' on 'Network Status')
Have a mark for read/unread messages, display total unread messages in the 'Inbox' tab text field
Change some of the status messages for the messages to be simpler (like 'Doing necessary work to send the message'):
- 'Sending...', 'Sent', 'Delivery confirmed'
- Separate columns for datetimestamps of time message sent and time of confirmation receipt in format (YYYY/MM/DD, 00:00:00)
The explanation of the deterministic and random addresses can be simplified. Call such addresses "random address" and "passphrase-based address", stating one is recoverable and the other is not respectively.

Just a bit of polish, basically. Sometimes it's hard to keep human language simple when you're developing something like this, but the program UI itself feels almost like the documentation for the program.

- Permanent tray icon - Notification pop-ups from tray when message received when window is not in focus - Switch to 'Send' tab when selecting 'Send message to this address' from 'Address book' tab - Capitalise the 'b' in 'book' on the 'Address book' tab (or drop the upper-case 'S' on 'Network Status') - Have a mark for read/unread messages, display total unread messages in the 'Inbox' tab text field - Change some of the status messages for the messages to be simpler (like 'Doing necessary work to send the message'): - 'Sending...', 'Sent', 'Delivery confirmed' - Separate columns for datetimestamps of time message sent and time of confirmation receipt in format (YYYY/MM/DD, 00:00:00) - The explanation of the deterministic and random addresses can be simplified. Call such addresses "random address" and "passphrase-based address", stating one is recoverable and the other is not respectively. Just a bit of polish, basically. Sometimes it's hard to keep human language simple when you're developing something like this, but the program UI itself feels almost like the documentation for the program.

Atheros1 commented

2013-04-01 17:47:21 +02:00

(Migrated from github.com)

2- I worked on this for about an hour without success. I can work further on it.
3 was a conscious decision that probably will receive endless debate. The current behavior lets a user add many recipients easily.
4 can be fixed.
5- I would like this as well
6- Currently Bitmessage doesn't keep track of both the sent time and the confirmation time. Though it could. "Sent" by itself is ambiguous.
7- Unfortunately it cannot be simplified. That does not give the user enough information to make an educated choice. Why would anyone want a "Random" address when they believe that they should be able to get a non-random address that is human meaningful? Programmers have a terrible habit of making language much too abstract to the point where the users do not understand what the program is doing, what it is asking, and what the real pros and cons of the options are. This "simple" human language leads to nothing but user confusion and consternation. The program- and indeed all programs- should read like a manual: explaining the options and letting the user make an informed decision. This is why "Wizards" came into existence. Apple popularized minimalist design because they were the only ones smart enough to hide options that the user need-not be shown in the first place. But if we Do ask users to make a choice, they have to be confident in it and we have to provide enough information to them to enable that.

Thank you for your suggestions

2- I worked on this for about an hour without success. I can work further on it. 3 was a conscious decision that probably will receive endless debate. The current behavior lets a user add many recipients easily. 4 can be fixed. 5- I would like this as well 6- Currently Bitmessage doesn't keep track of both the sent time and the confirmation time. Though it could. "Sent" by itself is ambiguous. 7- Unfortunately it cannot be simplified. That does not give the user enough information to make an educated choice. Why would anyone want a "Random" address when they believe that they should be able to get a non-random address that is human meaningful? Programmers have a terrible habit of making language much too abstract to the point where the users do not understand what the program is doing, what it is asking, and what the real pros and cons of the options are. This "simple" human language leads to nothing but user confusion and consternation. The program- and indeed all programs- _should_ read like a manual: explaining the options and letting the user make an informed decision. This is why "Wizards" came into existence. Apple popularized minimalist design because they were the only ones smart enough to hide options that the user need-not be shown in the first place. But if we Do ask users to make a choice, they have to be confident in it and we have to provide enough information to them to enable that. Thank you for your suggestions

ghost commented

2013-04-01 18:13:07 +02:00

(Migrated from github.com)

Regarding: "Switch to 'Send' tab when selecting 'Send message to this address' from 'Address book' tab"

Surely they can just select multiple addressees to send to instead of adding them one-at-a-time?

Regarding: "Switch to 'Send' tab when selecting 'Send message to this address' from 'Address book' tab" Surely they can just select multiple addressees to send to instead of adding them one-at-a-time?

Atheros1 commented

2013-04-01 18:42:15 +02:00

(Migrated from github.com)

That would definitely be ideal, yes. I'll add it to the feature request list.

ghost commented

2013-04-05 00:22:49 +02:00

(Migrated from github.com)

Just noticed another thing, I cannot delete (or rather, select) multiple messages via the UI.

Atheros1 commented

2013-04-06 00:04:32 +02:00

(Migrated from github.com)