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 Improvement Suggestions #74

Closed
ghost opened this issue Mar 26, 2013 · 5 comments
Closed

UI Improvement Suggestions #74

ghost opened this issue Mar 26, 2013 · 5 comments

Comments

@ghost
Copy link

ghost commented Mar 26, 2013

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

Atheros1 commented Apr 1, 2013

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

ghost commented Apr 1, 2013

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

Atheros1 commented Apr 1, 2013

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

@ghost
Copy link
Author

ghost commented Apr 4, 2013

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

@Atheros1
Copy link
Contributor

Atheros1 commented Apr 5, 2013

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

Just implemented this.

henrikolsson pushed a commit to henrikolsson/PyBitmessage that referenced this issue Nov 9, 2015
PeterSurda pushed a commit that referenced this issue May 2, 2016
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

1 participant