Please take a look at the flow below. We have two scenarios. One is when someone is exporting with a keystore, the second with Seed phrase.
Change_Wallet_Flow.pdf (674.2 KB)
All designs:
I'm presuming from the title that this is about the flow to change the current active wallet.
I'll probably check back later for the design changes itself, but:
I suggest we limit the changes to the UI visual design. When it was changed for the Settings for the import/create/export sprint, I explained it away to myself with this rationale β the Settings screen is a less often visited screen and that it is not uncommon for the Settings screen to be slightly different from the app, so some inconsistency is acceptable. After all, our transaction details screen has a similar look and hasn't been adapted to be consistent too.
Ditto for the tab bar. It's relatively standalone as long as icon styles are thought out.
But a quick look at this flow to change wallet and it looks like we'll be changing the fonts as well as the navigation bar in the Wallet tab. This means these changes have to be propagated to every other part of the app to preserve consistency and seems like an unnecessarily expensive change. I'm not a fan of the current look and feel with the rounded corners as well as inefficient use of space but IMO, while look and feel is important, and the "look" part of it plays an important part of a good app, the "feel" part of it is much more important. And it sounds like our goal was to improve the latter, not the necessarily the former. Has that changed? [1] And don't we already have some visual redesign planned? Those wouldn't be compatible anymore. Is that still going to be used? We already had some visual tweaks across most parts of the app a few months ago; I feel we shouldn't do it too often.
[1] And if that goal has changed, then I still suggest we go ahead with 1 core change at a time, and scope it down as much as possible. If we have to refresh the visual design, lets do some of it across the entire app first, before adding or changing any functionality. But I think it's easily a 2 weeks job or more just to change visual design across the app consistently. If we are concerned about what is being presented to the user, we can aggregate multiple sprints before shipping to the app store.
I completely understand your concerns. Let me explain where I am coming from.
First and foremost, it's difficult to work on something that is already not aligned with Material Design guideline. Coz at the end of a day, what should I follow if not Material Design?
Of course, I can mimic the current design, but some screens are badly designed. And I don't recommend to go with this solution. Take a look at the example below:
Can you read the yellow text? Does it look like a tooltip or another card?
So what was provided to me at the very beginning are screens made for iOS (or a hybrid between Android and iOS in Sketchapp). I could not find any screen made for Android (360x640). I asked @weiwu.zhang if I should:
A) always create a version which will be the easiest and fastest to implement on both platform or B) create a version for Android (according to the guideline) then adjust the iOS version
And I was told to go with B)
So from user experience, standardization is a big plus, because users know what to expect. They can predict certain behaviors because they are familiar with patterns. It's a mental model.
Google's Material Design is one of the most influential visual philosophies in design. It's shaping the way people see and interact with interfaces because of clear design and usability guidelines. And it helps to implement fast.
Recap:
- If I will have to follow someone else design style it might kill my performance and the quality of my work.
- What should I do in a situation where from the user experience perspective something is badly designed and I have to follow the pattern just to stay consistent? Shall I make mistakes on purpose and not follow what I was learned?
Example:
I suggest we can connect tomorrow and discuss this issue. Let's find the right balance between not spending too much on UI and getting my job done right as UX. I can't imagine making mistakes on purpose.
And if that goal has changed, then I still suggest we go ahead with 1 core change at a time
I'm impressed that you discovered the font has changed, I only discovered the border and material design change in the pictures.
Tomek's story is about UX, let's find out if we have any feedback on the story (how the user gets through screens and dialogues to get the wallet changed). I think the only the icons for the setting items are to be implemented, but even that is not the big deal. The flow matters more.
Basically, I recommend iOS implementation does things in its own way with minimal effort and apply common sense on what is minimum. This style of working saves a huge amount of time but is only possible with implementors extremely good at common sense, which Ξ±Wallet ios currently has (Boon)
1 Like
The font remains the same - SourceSansPro. But it's Regular and not Light. Small change, but more readable text. This is not so time-consuming to change I guess?
@hboon If there is a screen that can't be easily implemented - let me know and I will make you a custom design tailored for the current design. But it is an extreme situation I guess.
Ok. Thanks 
I prefer to think font-change is ad-hoc rather than project as the change is requested outside of a general visual project.
-
ππ-βππ: Any change that can improve UX with one or two small changes, file individual issues against ios/android project github.
-
πππππππ‘: Any change that requires a serial of changes for its integrity: start a project or incorporate into an existing project and send it to the monthly iteration pipeline.
So font change is ad-hoc. You can file individual issues against android/ios and πππ‘ mention it in the πππππππ‘'s implementation briefing (which is now in the format of screen description).
A few notes about filing issues for ad-hoc:
-
assign to James Sangalli by default. He manages the issues for now and he is the only one who can develop on both Android and iOS.
-
let implementors know how to get graphic collaterals. π.π. in the case of replacing icons you can simply attach the graphic collateral in SVG.
-
by filing an issue, it may be solved any day, outside of project iterational timeframe. e.g. it could be solved after the project is done. This allows the lead devs (Boon and James Brown) focus on integral changes on their own battle fronts.
-
when you file two individual issue to two platforms (ios/android), refer to each other in the issue.
-
I prefer to think replacing of 4 bottom icons and the replacing of settings icons ππ-βππ instead of part of Project: Key Backup and Restore
I had assumed the font change was a product of the prototyping software. Most Android apps stick with Roboto Google font for consistency. But I don't have a strong opinion on it. Just bear in mind it may look 'foreign' on Android.
The only part I would want to change is the json export. The help screen is lodged in between the intent button and the action itself. I'd be inclined to put that help screen on a 'What is this?' style hyperlink/button.
Looks good though.
Re: Boon's points, is the plan to upgrade parts of the app over time or everything together?
FYI: Android uses the same background asset for all the token views so it's fairly easy to upgrade in one go.
Re: Boon's points, is the plan to upgrade parts of the app over time or everything together?
To give an answer to that, we do things either ad-hoc or by project.
- ππ-βππ: Any change that can improve UX with one or two small changes, file individual issues against ios/android project github. The devs may or may not do it.
- πππππππ‘: Any change that requires a serial of changes for its integrity: start a project or incorporate into an existing project and send it to the monthly iteration pipeline.
In this case, font change is ad-hoc (goes to git issue) and not part of a project. The current project focus is key backup restore. We don't do UI overhaul now or any time soon. Android don't change to material design and change colour schema and make branding work in the next 3 months and I actualy don't see it happen in 2019 at all.
Few comments are made on the actual flow and much discussion is on something I wish to marginalize (font weight change), let me discuss the flow to get the focus back.
Since the old "Wallets" now is obsoleted by "Change Wallet", where does a user add a new wallet?
I do not wish to make such a feature prominent at the wallet page because the feature is rarely used and because that multi-wallet support is adding confusion now that we already support multi-chain.
Wherever you place the new wallet function, please make sure the user gets an opportunity to back it up soon after its creation yet are not forced to do so.
-
It looks like the screen shown after tapping "Change Wallet" is still the original "Wallets" screen, but modified to handle different types of "wallets". It is still the original "Wallets" screen because it provides access to managing (i.e. renaming/deleting/exporting) them. I suggest we still call it "Wallets". Be it "Wallet" or "Change Wallets", since the screen is used for managing wallets, the create wallet screen can still be in there like before?
-
Presumably, keystore-based wallets would be legacy now. Let's consider not showing the section titles "HD Wallets" and "Keystore Wallets" if there are only HD Wallets (even if a user had keystore wallets and deleted all of them). Perhaps also not showing "Keystore Wallets" if there no HD wallets. It feels like it would invite unnecessary questions.
-
The icon colors for icons in the Settings and "Change Wallet" screens don't seem to match. The lighter one looks a bit better.
-
A suggestion for improving wallet deletions: if the wallet has Ether > 0 on mainnet, we make the user press and hold the delete button for a few seconds to delete it. Maybe also check if they have any tokens (which we have detected). We can take this out of this sprint even if we want to implement this.
-
I remember someone (Weiwu maybe?) mentioned that a user feedback that when they are presented with the (iOS?) sharing sheet for backing up the keystore file, they don't know what it means or what to do. If we want to address that, in the "Set Keystore Password" screenshot with the "SHARE KEYSTORE" button circled, shall we show a message after they user taps "SHARE KEYSTORE" to explain what to do with the sharing sheet?
-
In the Settings screen, I see the "Back up this Wallet" has been added. I suppose this is intended to make it obvious to the user that that is available. Something to consider: we can also make it an accessory to the "My Wallet Address" row. So it becomes like:
[icon] My Wallet Address [BACKUP WALLET]
Perhaps in red or green, with a pill background. Helps to highlight the action and also lift it to top of the screen.
- In the "Change Wallet" screen, the shield icon reminds me of the Trust app and they happen to use it in their version of this screen too, so it looks really similar. Any chance we can replace it with another icon?
Can't agree. The change is intentional because we don't want to risk the user to miss the button amist learning the concept that there are multi-wallet support. That is, a user who never uses multi-wallet (99% of normal users) should be able to backup without knowing multi-wallet as a thing exists.
Our guess was that when the user wants to change wallet, the keyword in his mind is "change wallet" and if we show "wallets" it represents a small moment of learning, and as you probably know with a kid in the family, no one likes learning (well, at least my rascal).
Also "Change-wallet" represents an opportunity to learn that there can be many wallets, "wallets" assumes the user knows there can be multiple wallets in advance, which also assume the user's language has plural (Chinese don't) or that the user paid attention to the trailing -s.
But this guess can tested and we better get used to testing. I'll ask for a few draft (in a few minutes) a few versions. Implementation kindly go with the current way by default.
Regarding where to put delete button (it perhaps won't be called delete, see below), I am not concerned that having it in Change Wallet creates any confusion. Google user had no problem to delete an account in the "Switch Account" screen. Semantics give way to convenience. But we should find out in a test.
Yes. Agree with your approach and I prefer this to be implemented ππ-βππ, not in a project scope, because it's rarely used (unlike github project, a wallet is not shared online so people have little incentive to explicitly delete them) and we can't let a rarely used feature choke iteration delivery.
Now my opinion: we should, instead of offering "delete wallet", call it "lose wallet". Reasons: 1) deleted items sometimes can be undeleted, and trashed items can be restored. Lose is unambiguous. 2) a wallet can never be deleted from the blockchain. Technically you just lose access to it if you "delete" it.
Yes.
Agree. I added the note to the slide in Zeplin.
[quote="hboon, post:12, topic:239"]* The icon colors for icons in the Settings and "Change Wallet" screens don't seem to match. The lighter one looks a bit better. [/quote]
Use common sense when implementing (if Tomek hasn't already perfected it before you implement it).
Messages must be added. Here is the message before "password" input:
"KeyStore is always encrypted, otherwise whoever has it can gain the money."
Message beofre the "Share button"
Once the KeyStore backup is created, you can save it somewhere by sharing it to another app. We recommend a file management app or anything that doesn't send it over the Internet.
Further, "Share via" can be changed to "Save via".
Yes, we must.
What has changed?
- "Lose this Wallet" instead of "Delete this Wallet"
- Added "KeyStore is always encrypted, otherwise whoever has it can gain the money." before the password (it's below) the input field
- Changed "Share via" to "Send via" and updated the secondary text to "Once the KeyStore backup is created, you can save it somewhere by sharing it to another app. We recommend a file management app or anything that doesn't send it over the Internet."
- I removed Wallet Names (labels) and kept the balance instead (like in the current version)
- I kept (wrong on purpose) section titles such as "HD Wallets" and "Keystore Wallets" in the flow, but they are not included in the final designs. I kept them just to make the flow more understandable.
Updated flow:
