This is in regards to the Trello card no. 62
So instead of "Transactions", we would have "Activity". Then we can push local notifications from tokens, dapps, transaction statuses, etc. If this get complex segmented control at the top might be required + search box.
On the right, you can find another concept for iOS (large Title).
The tab design on the upper right corner might lead to potential confusion. Say, a user clicked 'activity' is likely to be in "Searching" mode, not "Explore" mode. He might have a specific activity to look for.
I think I got a message that I can vote now. Where is that message? Damn I forgot which DAO it is about, I had to find it in the Activities
Therefore, he will be confused if the Activity tab is not all-inclusive, that he might be in the "Transaction" tab instead of the "Token" tab, therefore, didn't see the event.
On the other hand, the categorisation requires prior knowledge - the user needs to know the difference between "Transaction" and "Token" activity.
On top of that, sometimes an activity item is both a Token activity and a Transaction (typical example: purchase of a kitty).
Suggestion: we borrow the INBOX concept, that you might have a lot of different email folders, but you only have 1 INBOX. Remove the tab design and a few years later, if needed, add filter function or tagging for those who have too many stuff in INBOX and wants to look at specific activities.
My 2nd suggestion is based on this of your draft:
There I think we mixed notification in the activities. These items are activity items:
These items are notification items:
The difference is like event notification and calendar entry. If you agree with this approach, kindly provide an activity vs notification picture in your draft.
Regards
Suggestion: we borrow the INBOX concept, that you might have a lot of different email folders, but you only have 1 INBOX. Remove the tab design and a few years later, if needed, add filter function or tagging for those who have too many stuff in INBOX and wants to look at specific activities.
I like this approach. I will upload new designs tomorrow. Studying Facebook, Instagram, Linkedin, banking apps and how they deal with notifications.
Please take a look one more time on the Activity Tab concept.
I decided to get rid of divisions on Transactions and Tokens. Right now they all look like tokens. So in case "Received ETH" or "Sent ETH" you will not see any arrows (like currently or in any other crypto wallets), but just an ETH icon instead. Then, the value with "+ 4.563 ETH" on the right.
If you have been notified (push notification or local notification), but you couldn't act because you were on the meeting, you will be able to browse all notifications when you hit the "Notifications" icon.
For upcoming events, you can use "Calendar" icons. We can Get inspired from Facebook or Linkedin. The design is not ready yet.
So the Activity tab will be a container for all activities from tokens.
All Coins and Tokens will have activities locally:
In the future, we can add advanced filters, contextual swipes, send/receive indicators.
You can leave comments on a single screen in Sketch Cloud. https://sketch.cloud/s/e4OJW/p/activity
My suggestion: only send/receive show +/- before number. For other activities like “convert sai to Dai” “deposit to compound”, and etc., just show the number without +/-.
Good. Makes sense.
I appreciate having to remove the up and down arrows because the 2 lists are unified. But then again, keeping the up and down arrows and being a bit inconsistent here (by not showing the token icon) might be worth considering too because I imagine it'll be quite common for users to look for send/receive transactions.
But what's the rationale for not showing the send and receive amount with colors (green and red)?
I thought that was the original reason for renaming the tab from Transactions. Is "Your FIFA ticket is redeemable now" triggered as a push notification?
Where are notifications displayed then? If it's another screen revealed when the bell icon is tapped, what do you think about about bringing back the segmented control? 1 for transactions, 1 for notifications and keep transactions selected by default to avoid users ending up in the wrong tab?
@weiwu.zhang: Are we going to store the (assuming push) notifications on a server? If we don't store it on the server (yet), we could consider just using the platform's Notification Center/Panel to display it
It will be worth considering a couple of use cases, and how they are solved from the wallet tab vs activity tab.
For users looking for a recent transaction (in the smart-contract sense), this activity tab allows them to have everything in chronological order. If they want a particular token, they can filter with the text field above, then click to see recent transactions of that token.
The current way of doing the same thing is from the wallet tab: search by name, click on token to see recent transactions. The use case made easier by Activity is when looking for a pair transactions of different tokens. Eg approve dai, and receive sai. Potential problems might be noisy tokens, but this is solved by "Delete" ("Archive"? Can they bring them back?).
Future thought, we could consider combining the two? (like how Telegram works, but channels and messages are tokens and txs respectively). The consolidated view shows tokens as per the wallet tab, sorted by most recent transaction of that token. Like telegram, these can be pinned (eg Ethereum). But the case of searching neighbouring txs of two tokens would still need attention.
I thought that was the original reason for renaming the tab from Transactions. Is "Your FIFA ticket is redeemable now" triggered as a push notification?
Notifications are not activities by example:
Let's say you have voting right for the director of the board and the vote closes 10PM, there are 3 scenarios what could be on display in the Activity tab:
| Scenario | Activity Time | Activity Item message | ||
|---|---|---|---|---|
| 𝑓𝑢𝑡𝑢𝑟𝑒 | 10PM | Voting closes midnight [countdown: 3 hours] | ||
| 𝑝𝑎𝑠𝑡 | 10PM | Voting closed and you havne't voted. | ||
| 𝑖𝑟𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡† | 7PM | You voted for "Weiwu Zhang" |
† "𝑖𝑟𝑟𝑒𝑙𝑒𝑣𝑒𝑛𝑡" denotes the scenario that the expiration time of the vote is irrelevant to the current user (beacuse he already voted).
And the corresponding notification is:
If the user clicks that notification message, sees the voting action, made the vote, then it's the 𝑖𝑟𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡 scenario. If the user didn't click that notification in 10 minutes, then it's the 𝑝𝑎𝑠𝑡 scenario. If the user didn't receive the notificatino yet, then it's the 𝑓𝑢𝑡𝑢𝑟𝑒 scenario.
in the 𝑓𝑢𝑡𝑢𝑟𝑒 scenario, if an event is so important that you get 3 notifications, 1 day, 1 hour and 10 mins before, You don't need to see 3 notifications each says "1 day", "1 hour", "10 mins" and work out what each one of them means by adding that time to the timestamp of the notification. ("Oh I received a notification that says 10 minutes left, and that was 8 minutes ago, so it is 2 minutes left."). Rather instead, one count-down in the activity section is enough no matter how many notifications.
Outside the 𝑓𝑢𝑡𝑢𝑟𝑒 scenario, You also don't need to seem the notifications at all in Activities if you have already voted, again making notification not equivalent of activities).
You can have a future activity a few months ahead of the time which doesn't have a corresponding notification until pretty close. Like FIFA ticket.
Thanks to the distinction between activities and notifications, there is no need to store notifications in the app itself. We go for the platform's notification area. With such understanding, Tomek is only showing the activity tab concept in this thread.
If you open a token/coin, you only see last 3 transactions and there is no way to see more unless you go to "Transactions". This is how it works now.
Scenario: You are raising funds for a new, cool project. Your friends promised to donate you. You accept any coin. They sent DAI, xDAI, ETH, USDC, LINK. With this model, you have to open one by one to see what's the balance and when they sent it. Activity tab solves this problem. It's kind of like an aggregator.
I got it. They simply don't look good. It looks cluttered to me.
We already have two indicators that a transaction was incoming or outcoming. This is "+ /- " before a value, and the title "Sent ETH" or "Received ETH".
We can think of a gentle way to flag it. How about the one in the middle? What do you think?
Also, let's not forget that red–green color blindness affects up to 8% of males.
Calling them A, B, C:
B looks a bit nicer than C at first glance, but C is nicer to scan because the amounts and color is on a narrow column.
Anyway, this (although it's still some work) is not that difficult to switch between B and C. So both are fine with me.
I look at the built-in iOS Stocks.app and imagine that it will be harder to read if red/green colors are removed:
| Red/green | black (grayscale here) |
|---|---|
 |
 |
We already have two indicators that a transaction was incoming or outcoming. This is "+ /- " before a value, and the title "Sent ETH" or "Received ETH".
If it's too noisy, what if we do something like B/C and replace both "Received ETH" and "Sent ETH" with "ETH"?
Also, let's not forget that red–green color blindness affects up to 8% of males.
They are way more affected by tint colors, so as long as the foreground + background has high contrast, it's still usable 
A tweak to help you is to let them tap on a "more" button below the 3 transactions and switch to the Transactions/Activity tab and automatically apply an appropriate filter for that token. (or pop up a new instance of the Transactions/Activity screen instead of switching tabs, so it's easy for the user to hit back/close and go back to that token).
@Tomek suggestion: green for the incoming values, but change the outgoing values from red to black, so it's more neutral. Could it work?
To avoid confusion for converting (DAI to SAI), instead of displaying the value as a debit (3.567 DAI), display the value as credited [ + 3.567 SAI ]
This aspect of crediting, I think it would be more useful as users might find more useful to know the current state of their assets (they now have SAI) rather than the past change (they gave up DAI).
—
Also, an idea for consideration that came mind on these:
Having "subordinate" activities, using an example of how Apple presents notifications in groups that you tap to see related content.
In this case, certain activities can be seen as top-level summaries, with subordinates underneath available on tap. To draw a specific example, the user sees:
[ You Issued A Vote For Issue #5530 ]
Instead of...
Where this has the advantage of making the information more relevant to the goal (e.g. issue a vote) and avoids fragmented scenarios which are difficult to analyse the ongoing/outcome result because of how the activity stream presents information.
Would need some user feedback to understand if users have enough activity that fragmentation is a problem. Which means maybe for a future version.
Other hypothetical activity cards and what's below:
[ Ongoing Donation Via MagicLink ]
[ Converted SAI to DAI ..... + 500 DAI ]
There have been a few successful designs where the same object can be accessed from more than 1 places, e.g. for accessing files, Windows has Recnet + Favourite + My Documents.
I tried a bit but couldn't get what you mean here, starting from the 2nd sentence. But since we are on the topc of future thoughts, there is the smart token thing where recent activities are not an integral part of the UX, weighting against any design that forces the display of tokens with its transaction history together.
For example (these examples were to be conceptualised for the April EDCON by our former collage Farrah. She might have delivered it in the end, but I couldn't find it quickly from Drive)
For these tokens, the most relevant information is not recent activities. (A quick way to access activities is still needed - just that it's not the most relevant information).
From these "smart tokens" back to today's dull payment tokens. As Farrah illustrated in the docs for payment tokens, typically, the most relevant information is made up of those types:
Note that "Activities" as curently is can't cover 𝑏-𝑑 because they are not ordered by most-recent (you can keep a payment channel open for a year if you like).
Keep going on on the open state channel example, a modified Activities might work a bit - if you borrow the messenger paradigm, making an open state channel a **sticky activity"*. Or an alternative design approach might be used since state channels are different than the activity that opened it, like for example, a state channel can have its own activity list which isn't visible on-chain; you can close a state channel which you can't do to activities,
Today, understandably only 𝑎 is available (we haven't implemented the rest in TokenScripts). I hope "Activities + Predefined Filter" can be designed as a widget to fill 𝑎's role.
