Open hamidsafdari opened 1 month ago
Feedback for some points:
Public Keys: When the app asks to generate Public Keys, is this necessary for server operation? If yes, perhaps it would be smoother to generate them automatically, allowing users to regenerate/replace the key later if needed.
Public key is required if SFTP server is selected. The app checks for that and asks for key generation only if it is needed. You would change it to not show the dialog? I think that would be ok.
What are the downsides of defaulting the authentication to "Anonymous" or setting a default username/password (e.g., "user"/random password)?
Security. This is a topic that can heavily be discussed. People have very different and strong opinions in this regard. I would not do changes here.
Current center alignment makes it harder to find key information like the server IP. Left-aligning elements could make them more readable.
Lol. Some years ago it was left aligned and people asked to change it to center alignment :smile:
Showing server IPs and ports in readonly text inputs with action buttons (e.g., copy, generate QR code) might be clearer and would eliminate the need for a separate QR tab.
Could to show a draft how it could look like?
If anonymous authentication is selected, there’s no need to show username/password fields in the main tab.
Yes, that is true. It would require some extra code to hide stuff that is not needed. It would lead to some additonal test effort to check if the UI looks ok with different settings.
Currently, the app asks the user to select a directory each time a storage type is selected. Could this be optimized?
This is about details in handling of SAF API. In meantime there are some hints in README how you can avoid to be asked that often.
Storage Type Dropdown
Could be changed. The link to this GitHub page would needed to be placed somewhere else then.
Permissions might be better requested only when needed
Basically it is like this. But could probably be improved. Some years ago that was much different.
There’s a noticeable unused space to the left of preferences
A PR for that got merged in meantime :+1:
Preferences don’t currently show the selected value.
How would this be done nowadays (sample code, PR)?
Instead of showing all options, make it a dropdown with "Anonymous", "Username/Password", and "Public Key". Show/hide fields dynamically based on the selected method. Descriptions could be shown for the "Public Key" option upon selection.
Same as last point: How would this be done nowadays (sample code, PR)?
I won't avtively work on these things. But I'm happy to review PRs :wink:
Currently, the app asks the user to select a directory each time a storage type is selected. Could this be optimized?
This is about details in handling of SAF API. In meantime there are some hints in README how you can avoid to be asked that often.
If I understand correctly, the issue is that:
The solution is maybe something like:
What about Android revoking permission to slected dir after some time? At least docs indicate that would happen.
IMO it is not a big issue as last selected dir is still pre-selected. It is just one touch to get the dir-picker out of your way.
What about Android revoking permission to slected dir after some time?
Oh yeah...... :( Hmmm, maybe if we can detect this, then pop-up the selection. But you are right, not a critical issue. - Though it took several month for me, to realize, I can click the back button... Don't laugh... :D It is only "critical" on devices, where we have to select a subfolder, start it up, then select the root of the SD card, if the user doesn't use the back button (like me), it is a bit annoying.
another thing regarding
Authentication Dropdown
Currently users can select multiple authentication mechanisms at the same time, e.g. username/password and public-key. With a dropdown this would not be possible anymore.
Current center alignment makes it harder to find key information like the server IP. Left-aligning elements could make them more readable.
Lol. Some years ago it was left aligned and people asked to change it to center alignment 😄
This is what the UI looks like without center alignment:
I've also added tools:text
to all TextViews so the UI is previewed correctly in Android Studio:
I've made a pull request (#402) in case you find it better than the current layout.
@wolpi, I'm trying to automate public key generation and remove its dialog. Would it be OK to generate the keys only once after the user runs the app for the first time?
Also, I've noticed a couple of things I don't understand:
KeyFingerprintProvider#areFingerprintsGenerated()
returns false every time the app is started. The value of fingerprintsGenerated
is merely toggled when calcPubkeyFingerprints()
is called. It doesn't check for any files or preferences. Do you think this is intentional? Is there a need to generate new keys like this?What are the downsides of defaulting the authentication to "Anonymous" or setting a default username/password (e.g., "user"/random password)?
Security. This is a topic that can heavily be discussed. People have very different and strong opinions in this regard. I would not do changes here.
When the user wants to start the app after install, they get a toast saying they have to set an authentication mechanism first. I'm just saying this could be made straightforward. If security is a concern, the default authentication mechanism could be username/password with a static username but a random password that gets generated after first run. That way even if someone knows you have this app installed, they can't guess the password. I also think the password should only be generated on first start so the user can save it on their client.
What are the downsides of defaulting the authentication to "Anonymous" or setting a default username/password (e.g., "user"/random password)?
Security. This is a topic that can heavily be discussed. People have very different and strong opinions in this regard. I would not do changes here.
When the user wants to start the app after install, they get a toast saying they have to set an authentication mechanism first. I'm just saying this could be made straightforward. If security is a concern, the default authentication mechanism could be username/password with a static username but a random password that gets generated after first run. That way even if someone knows you have this app installed, they can't guess the password. I also think the password should only be generated on first start so the user can save it on their client.
This would still have secuirty issues:
An idea would be: Show a dialog on first launch to let user choose it's authentication mechanism. That might be structured different than preferences (simplified dialog to store chosen option in preferences).
@wolpi, I'm trying to automate public key generation and remove its dialog. Would it be OK to generate the keys only once after the user runs the app for the first time?
Also, I've noticed a couple of things I don't understand:
1. `KeyFingerprintProvider#areFingerprintsGenerated()` returns false every time the app is started. The value of `fingerprintsGenerated` is merely toggled when `calcPubkeyFingerprints()` is called. It doesn't check for any files or preferences. Do you think this is intentional? Is there a need to generate new keys like this? 2. It looks like the only keys generated are the ones in the main tab (checked in 7.2 and master). Are the rest of the keys generated when some preference is toggled?
These were my thoughts how key-generation should currently work:
I've compiled a list of potential UI improvements that could help make the app more user-friendly and reduce clutter. These changes aim to simplify the interface, improve the user experience, and optimize space. However, I'd love to hear from other users to ensure that these changes align with what the community needs. Here’s a breakdown:
General UI
Main Tab
Clutter Reduction:
Directory Selection: Currently, the app asks the user to select a directory each time a storage type is selected. Could this be optimized?
Storage Type Dropdown: Radio buttons are cramped and flagged by Android Studio for their short height. A dropdown with descriptions displayed on selection might be a better fit for touch screens.
Permissions: Permissions might be better requested only when needed (e.g., request Notification permission only when enabling notifications and pressing start).
Settings Tab
Feedback Request: These are just my initial thoughts on how to improve the UI, but I'd love to get the community's opinion. If anyone has suggestions or feels differently about these changes, please share your feedback!