Great job. There are a few things I would love to see in the future for an application like this.

I think the application should also be able to generate a 256-bit entropy password as well (like steemit.com does) so that the user can use that password to derive multiple keys rather than only generated single keys that are isolated from one another. That way, a user can generate a single key for the owner authority, and generate a single password which they then use to derive the active and posting authorities as well as the memo key, for example. I suppose they could already use the randomly generated public key as a passphrase, but that could quickly get confusing for the user since their passphrase would look like a public key. The UI could also be streamlined for it so that they don't need to copy and paste the randomly generated password into another field in order to update their account to use the derived keys; they would just click the button to randomly generate the passphrase and then click checkboxes to determine which of the authorities/keys (owner, active, posting, memo) of the account should be derived from that randomly generated password.

Also, I think the UI should put less emphasis on the ability to derive keys using a user-chosen password. That could be a hidden away advanced feature. Most users cannot be trusted to choose a safe enough passphrase that won't be bruteforced.

I think it is important to have a GUI that allows the user to choose the server and port of the steemd websocket to connect to, since right now it is hardcoded to Steemit's websocket.

Finally, I don't know if this would be in your intended usage for Steem Pressure, but what I would really love to see in an app like this is an offline mode. This ecosystem desperately needs some offline transaction signing tools, at the very least for just the limited operations that require owner authority authorization (which so far means either changing the owner authority of the account, changing its recovery account, or proving owner authority).

Under normal operation, the application could generate the transaction to be signed during online mode and write it out to disk. It could also be run in offline mode which would allow the user to: select the serialized unsigned (or partially signed) transaction from disk; see the transaction visualized in the app so that they know what exactly they are signing; input the appropriate private key or passphrase that derives the appropriate key to sign the transaction; and then finally write the new signed (or partially signed) transaction back out to disk. Users could then use flashdrives with a live Linux OS and this app to do offline signing on an air-gapped computer.