-
Notifications
You must be signed in to change notification settings - Fork 780
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
Various UX issues #1568
Comments
+ui/ux |
I'll try to add my perspective here, since this is a pretty long laundry list of things. Onboarding Information hierarchy Semantics Graphics Payment IDs Addresses Layout Error handling Cool to see this feedback. Would love to help address the parts that require design work. Just my 2 cents. I'm not fully aware of all the work that's happening though, so might be totally wrong here. |
Maybe not for all of them, but definitely for some of the easier ones: +hacktoberfest |
Regarding the payment ID, AFAIK the classical long (64 characters) payment ID format specified separately is discouraged and will be deprecated in the near future. The integrated address format (with a short payment ID integrated) and the newer subaddress format both will not cause this confusion. |
My main FRs for the gui related to usability would be (in no particular order):
thanks |
copied from some dude on reddit
Yup, without providing solutions then critique is useless. Here's a few issues.
Onboarding: There's a fundamental lack of onboarding and the wallet literally requires a manual to understand how to use it. Don't even get me started on the Ledger integration, but that's not Moneros fault IMO. Moving forward, it's easy to forget how confusing this space was when you first started but keeping this first time user POV is the key to simplifying products. There should be a mix of onboarding, tooltips, explanations and potentially links to video tutorials (for visual learners)
Information Hierarchy: The navigational components can (and should) be consolidated because they don't (IMO) justify their own nav items because there's simply not enough content, "Receive" being the main culprit here. As an example, Send and Receive can be consolidated into "Transfers" and address book can be a selector in the Send tab. Here, we went from 3 tabs to one. This type of consolidation is important because it lessens the cognitive load on users and provides the perception of simplicity which can be as important as simplicity itself.
Semantics: This is the lowest hanging fruit IMO. Protocol semantics should not be presented at the application layer. A few examples of current semantics that should be abstracted into simpler phrases: node, daemon, ring signatures (even though this is awesome) etc.
Graphics: This is a minor one but none of the images in the wallet are hi-res (svgs) they're all flat 1x pngs, so on retina devices all the assets are pixelated. This is such a small issue, but it's the small things that make an application feel safe, secure and trustworthy.
Payment ID's: Probably the most confusing things for new users. What is this and why is it important? What happens if I don't add one? How do I add one? Can I type in random chars? Is their char limitations? What do you suggest as an ID structure? Admittedly, these are really asinine questions, but trust me, these are the questions the average user asks themselves.
Addresses: When I create a new address what happens? Do I need a separate account for these wallets? Do all my balances show in this wallet? How many can I create? Again, such stupid questions but reflective of average user mental models.
Layout: There's a lot of layout issues and there's UI conflicts where things overlap, have inconsistent paddings, margins etc. We're not using grids at all so things look very inconsistent. This isn't the worst thing in the world because thinking about interfaces spatially and responsively is kinda hard. It's a little easier for me by virtue of the systems I've built but it's these kinda of things that contribute to the overall trustworthiness of the product because everything looks like it was intentionally placed where it is and thought about.
Error Handling: Errors aren't really handled very well in the system right now. There's two types of errors -- global and local. Local errors are for things like inputs. Right now the inputs are triggering a red input border but there's no assistive prompts that help a user remediate the issue. Each input should have a/some custom error message for example: The Address Book input error should say something like "That address couldn't be found, check your address book" as a shitty example. Global errors are for things like conflicts that prevent all actions from being performed. Something like "No internet connection" is a global error that should persist across all views no assigned to a local component.
The text was updated successfully, but these errors were encountered: