Updates to the receive and activity milestone pages (#114)

Based on the latest designs the team has worked on. Some more work to do, but it pushes things forward quite a lot from that's on the site right now.

pages/milestones/1-2-navigation.md

@@ -8,7 +8,7 @@ header: true
 
 # Milestone 1.2: Navigation
 
-**Status: Planning**
+**Status: Complete**
 
 _[Design milestone](https://github.com/BitcoinDesign/Bitcoin-Core-App/milestone/2), [Code milestone](https://github.com/bitcoin-core/gui-qml/milestone/2), [Figma](https://www.figma.com/file/ek8w3n3upbluw5UL2lGhRx/Bitcoin-Core-App-Design?type=design&node-id=7516%3A13168&mode=design&t=sZSBHpOLLJmoMf57-1)_
 

pages/milestones/1-5-activity.md

@@ -8,7 +8,7 @@ header: true
 
 # Milestone 1.5: Activity
 
-**Status: Early design exploration**
+**Status: Complete**
 
 _[Design milestone](https://github.com/BitcoinDesign/Bitcoin-Core-App/milestone/5), [Figma](https://www.figma.com/file/ek8w3n3upbluw5UL2lGhRx/Bitcoin-Core-App-Design?type=design&node-id=7529%3A16730&mode=design&t=sZSBHpOLLJmoMf57-1)_
 
@@ -23,33 +23,43 @@ In previous milestones, we added wallet creation and import. Now we add display
 	height = 384
 %}
 
-Below are explorations of various activity screen states. These will change as we get closer to the implementation of this milestone.
+Below are examples of various activity screen states. Note that activity includes both transactions and payment requests.
 
 - During initial block download when no transaction data is available
 - Blocks are downloaded and wallet has no transactions yet
+- 3 transactions and blocks are being downloaded
 - 3 transactions
-- Lots of transactions with pagination and expanded search & filter options
-- Active search with some results
-- Active search with no results
+- Many transactions requiring pagination, and expanded search & filter options
 
 {% include picture.html
 	image = "/assets/images/activity/screens.png"
 	retina = "/assets/images/activity/[email protected]"
 	big = "/assets/images/activity/screens-big.png"
-	alt-text = "Six mock-ups of the activity screen showing various content states"
+	alt-text = "Five mock-ups of the activity screen showing various content states"
 	width = 800
-	height = 1097
+	height = 1009
 %}
 
-On mobile, the layout slightly changes. Some horizontally stacked elements switch to a vertical layout.
+To find specific transactions, the user has search and filter options available. They are hidden by default.
+
+{% include picture.html
+	image = "/assets/images/activity/search.png"
+	retina = "/assets/images/activity/[email protected]"
+	big = "/assets/images/activity/search-big.png"
+	alt-text = "Five mock-ups of the activity screen showing various content states"
+	width = 800
+	height = 869
+%}
+
+On mobile, the layout slightly changes. Some horizontally stacked elements switch to a vertical layout. The biggest change is that the balance and primary buttons get moved into the screen, since there is no static tab bar.
 
 {% include picture.html
 	image = "/assets/images/activity/mobile-screens.png"
 	retina = "/assets/images/activity/mobile-[email protected]"
 	big = "/assets/images/activity/mobile-screens-big.png"
 	alt-text = "Two mobile screens showing a short and a long transaction list"
 	width = 800
-	height = 1013
+	height = 814
 %}
 
 Transaction types and states are visually respresented in shapes and colors.
@@ -64,18 +74,6 @@ Transaction types and states are visually respresented in shapes and colors.
 	height = 268
 %}
 
-Filter options are taken from the QT GUI and may change from these designs.
-
-{% include picture.html
-	image = "/assets/images/activity/filter-dropdowns.png"
-	retina = "/assets/images/activity/filter-[email protected]"
-	mobile = "/assets/images/activity/filter-dropdowns-mobile.png"
-	mobileRetina = "/assets/images/activity/filter-[email protected]"
-	alt-text = "Two dropdown panels with filter options with date ranges and transaction types"
-	width = 800
-	height = 218
-%}
-
 Various transaction states on mobile.
 
 {% include picture.html
@@ -84,7 +82,7 @@ Various transaction states on mobile.
 	big = "/assets/images/activity/transaction-status-examples-mobile-big.png"
 	alt-text = "Table showing mobile layouts of transactions states with matching labels"
 	width = 800
-	height = 1182
+	height = 1432
 %}
 
 Various transaction states on desktop.
@@ -95,17 +93,30 @@ Various transaction states on desktop.
 	big = "/assets/images/activity/transaction-status-examples-desktop-big.png"
 	alt-text = "Table showing desktop layouts of transactions states with matching labels"
 	width = 800
-	height = 652
+	height = 795
 %}
 
-An early iteration of a transaction details screen.
+#### Transaction details
+
+While a transaction always has the core information from the block chain, the amount of user-added context, which is often the most useful, can differ. So it should be easy for users to annotate the transaction.
+
+If a matching payment request could be identified, that information is also shown, and a link to view the payment request is added.
 
 {% include picture.html
 	image = "/assets/images/activity/transaction-details.png"
 	retina = "/assets/images/activity/transaction-[email protected]"
 	big = "/assets/images/activity/transaction-details-big.png"
 	alt-text = "A transaction details screen"
 	width = 800
-	height = 861
+	height = 580
 %}
 
+Also note the point in the [receive]({{ '/milestones/1-6-receive/' | relative_url }}) page, about how transactions and payment requests share the same basic layout.
+
+#### To-dos
+
+- Fee bump interaction flow
+- Cancel transaction flow
+- Indicator for address re-use
+- Clarify how payment request info is shown on the transaction page
+- Mock-up various transaction states, to show color and shape coding

pages/milestones/1-6-receive.md

@@ -8,11 +8,11 @@ header: true
 
 # Milestone 1.6: Receive bitcoin
 
-**Status: Early design exploration**
+**Status: Complete**
 
 _[Design milestone](https://github.com/BitcoinDesign/Bitcoin-Core-App/milestone/6), [Figma](https://www.figma.com/file/ek8w3n3upbluw5UL2lGhRx/Bitcoin-Core-App-Design?type=design&node-id=7516%3A13172&mode=design&t=sZSBHpOLLJmoMf57-1)_
 
-In this milestone we add features related to receiving. The main focus is on the receive tab, and we also need to display a history of past payment requests and payment request details.
+In this milestone we add features related to receiving.
 
 {% include picture.html
 	image = "/assets/images/milestones/1-6-receive.png"
@@ -23,35 +23,64 @@ In this milestone we add features related to receiving. The main focus is on the
 	height = 384
 %}
 
-At the center is the form to create new payment requests, which generates a new address. One address per transaction is a best practice to improve privacy and for easier identification.
+#### Creating requests
+
+At the center is the form to create new payment requests, which generates a new address with some user-defined payment information attached. One address per transaction is a best practice to improve privacy and for easier identification. Be aware of the note about label functionality at the bottom of this page.
 
 {% include picture.html
 	image = "/assets/images/receive/form.png"
 	retina = "/assets/images/receive/[email protected]"
 	big = "/assets/images/receive/form-big.png"
 	alt-text = "A form to create a new payment request"
 	width = 800
-	height = 551
+	height = 760
 %}
 
-Requests are meant to be shared with the payer, so the share options are in focus on the request details screen.
+##### Clarifying label functionality
+
+The QT application uses the label field for two conflicting purposes. 
+
+1. it is used to describe the newly created address for future reference for the user (which is the intent in [BIP21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#query-keys)). 
+2. the label is shared with the payment request with the expected sender.
+
+The sender most likely wants to label the address (or transaction) differently than the recipient, to match their own organizational setup (like the name of the recipient).
+
+Some examples might help clarify this:
+
+- Alice uses the label "Bob", so she can later tell that she shared the address and payment request with Bob. So Bob receives the payment request with his own name.
+- If Alice is aware of this and wants to ensure Bob knows who the payment request is from, she might use the label "Alice". This is helpful for Bob, but now Alice has an address that is labelled with her own name.
+
+That is why we split the label field in this design. One is attached to the address for personal reference, the other is shared with the payment request. The user can, for example, enter their name, so the recipient knows who the payment request is from.
+
+#### Viewing created requests
+
+The application treats payment requests as not-yet-completed transactions, which is why the screen layout matches that of transactions. Some considerations:
+
+- Requests are meant to be shared with the payer, so the share options are in focus on the request details screen.
+- Since all fields are optional, a payment request may be as minimal as just an address.
+- If the request has been completed, there is a link to the respective transaction.
+- The QR code is shown by default on mobile, but not on desktop, to reflect the difference in usage.
 
 {% include picture.html
 	image = "/assets/images/receive/request.png"
 	retina = "/assets/images/receive/[email protected]"
 	big = "/assets/images/receive/request-big.png"
 	alt-text = "Screen showing details of a single payment request"
 	width = 800
-	height = 565
+	height = 644
 %}
 
-All requests the user has created are available in this list screen, along with the status of whether transactions were received on the respective addresses or not.
-
 {% include picture.html
-	image = "/assets/images/receive/requests.png"
-	retina = "/assets/images/receive/requests@2x.png"
-	big = "/assets/images/receive/requests-big.png"
-	alt-text = "A list of payment requests the user has created"
+	image = "/assets/images/receive/request-variations.png"
+	retina = "/assets/images/receive/request-variations@2x.png"
+	big = "/assets/images/receive/request-variations-big.png"
+	alt-text = "Content and state variations of the request screen"
 	width = 800
-	height = 366
+	height = 546
 %}
+
+#### Request history
+
+All requests the user has created are visible in the [activity]({{ '/milestones/1-5-activity/' | relative_url }}) screen.
+
+The QT application treats payment requests almost as separate objects with their own screens for managing them. In this update, we try to blend them further and treat payment requests essentially as a type of transaction - one that is not completed yet. The screen that lists your own payment requests is removed, and that content is merged into the activity screen.