pierrelafitte
commented
3 years ago Hey @g45t345rt thanks for the feedback!
It's nice to get some critique, however I do respectfully disagree with it for many reasons that I hope to articulate below. This response should hopefully help expand some of the thinking behind the product architecture so we can attract nuanced critique in the future.
Generally speaking, the overall issue is that the feedback doesn't take into account design best practices, techniques for simplicity, information architecture or responsive web design. If you're interested in these techniques for reducing complexity I would recommend "The Laws of Simplicity" by Jon Maeda, and you can visit his website here: http://lawsofsimplicity.com.
Personally, I adhere to and implemented the following Simplicity Laws quite diligently:
Reduce: The simplest way to achieve simplicity is through thoughtful reduction.Organize: Organization makes a system of many appear fewer.
For the most part, your suggested menu redesign cannot be implemented due to the restraints of horizontal real estate, or in simpler terms, screen width. There's two tricks to solving these aggravating yet predictable issues.
First, avoid having more than five menu items. This is because when an application is resized into it's mobile break point (< 575px) , the left side vertical menu items need to transform into bottom based horizontal tabs -- unless of course you want navigation bar based, nested accordion menu items, where discoverability and user experience suffers as a consequence.
To avoid this negative tradeoff, it's best practice to have no more than 5 menu items (and hence why you never see native apps with more than 5 tabs) because when you focus on accessibility (most devices possible in this case, not WCAG guidelines) you need to account for a 320px screen width. When dividing 320px / 5 you get 64px which is the most amount of horizontal pixels you can have. Even with a excessively tight padding of 4px (actually 8px for left and right) you're left with 56px per tab. This is simply not enough space for excessively long navigation labels. As a tradeoff you'd have to change the font-size to something that is illegible because it would be beneath minimum recommend font sizes.
So in short, the number of items in the menu (6) and the length of the labels (8 - 19 chars) would break the responsive web design, of which you can see by resizing your window in either the Desktop or Web Application. So in this example by following the Organize rule above we can solve both issues with better organization via taxonomy and labels.
Second, your feedback is what I respectfully disagree with about the Monero application design, because there's many navigation items that can and should be combined into a single category, yet they're split out into separate pages and menu items, which increases cognitive load and complexity. Additionally, the labels of certain menu items in your critique, make assumptions about the primary use case of that page. For example, if I withdraw from an exchange I am not "Receiving Payments", I'm simply taking custody of my funds. The labeling logic is also inconsistent and slightly illogical because sending is called a "Transaction" yet receiving is called a "Payment". They should've both been called either "payments" or "transactions". Lastly, these labels are plurals yet the action is singular -- for example you can only send one transaction at a time, so calling it "Sending Transactions" isn't accurate and "Send a Transaction" is too verbose.
So in this example, the first rule Reduce seems to solve both issues. We can Reduce the complexity by categorizing Send Transactions and Receive Payments into Transfer. We can further reduce the complexity and simplify architecture by having tabs that then separate the Transfer logic into Send and Receive. The dual benefit of this is that it also solves the issues I outlined about horizontal real estate, will work on any mobile device, and makes no assumption about the intent of the action, thus making it intentionally generic.
One thing I do absolutely agree with you on, is the receiving address and the confusion about it's location for first time and/or new users. To be honest, I think at bare minimum it should be included (and was originally) in two places. It should be included on the Receive tab, because if you want to select a receiving address then selecting it here is logical and contextually obvious. However, if you're just looking for your address i.e to know what it is but with out the cognitive intention of receiving funds, then it's not obvious that it's in the Receive tab.
I think the solution to this is to add it to the Settings section under an "Address" header. I'll add this back in for the next version.
Hopefully this doesn't come across as illogically critical because I do value your feedback.
Pierre
g45t345rt
I feel the sidebar is little bit to generic. It might help to be more specific on what clicking a tab actually do.
From the screenshot below I've changed
Why My assets (using My implying that it's yours only) Convert your assets (it's more indicative that you want to convert assets and not something else) Send transactions -> leading to Transfer and Send tab (Thinking that I want to send XHV to someone, I feel like it's more obvious to click on Send transaction instead of Transfer) Receive payments -> leading to Transfer and Receive tab (if I think about Receiving XHV I'm looking for my address and right now it's not obvious that it's in Transfer and Receive tab) Customize your wallet -> leading to Select theme and other future wallet preferences Private keys -> leading to sensitive private keys (sensitive information like keys should be on another page and not mixed with settings)