Clicking on a transaction item brings up details of transaction

[haustraliaer]

This has opened up a broader issue of the overlay technique whereby...

If you scroll down the page (on history) and click an item that brings up an overlay (transaction) it will actually jump the user back to the top of the page - due to the fact that the content underneath must be position fixed.

I'm going to try and figure out a way of avoiding this - hopefully without too much css hackery - but we'll see.

[weilu]

What about instead of position fix what's underneath, just destroy the ractive instance all together and remember the scroll position; when user tries to go back to the history page, we re-instantiate the page again with the supplied scroll top?

[haustraliaer]

That was basically what I planned to do, the only problem being we want to "keep" the content visible below - so might have to reposition it relative to the scroll.

[weilu]

What value does it bring to the user with the content visible below?

[haustraliaer]

It's more jarring to transition into a completely new state, we would need to add a cancel / back button (rather than tap the screen anywhere to return). Throwing this one over to @jenbennings for his opinion from a UX/design pov.

I might create a separate issue for the overlay positioning though as it's not specific to the history tab and will likely come up again in future.

[jenbennings]

What value does it bring to the user with the content visible below?

Because as a user I know that I'm still in the history panel. The information you are presented with when you tap a transaction is merely an elaboration of what is already there in front of me. The reason we've used a fullscreen overlay for Waggle is that it requires multiple steps to pre-fill an input.

Perhaps an overlay (fullscreen or otherwise) is not the best way to approach this, given that there that are still some unknowns at this stage about what exactly goes in the transactions detail panel.

A fixed header (dun dun dunnnnn) could alleviate this problem.

This allows us to treat the transaction detail state as a secondary navigation style to the tabs (as opposed to swapping out the main nav entirely).

[haustraliaer]

As per our discussions last night we're going to park this to work on more important features for now.

[weilu]

• transaction id e.g. b11b6c500aecead4866998c970d057d8cda31915d86865c9a111b8a9cbd62909
• inputs (min 1 input, max can be however many) address a, amount a e.g. msS7Y9ri5zeVk4Rg6TdXigvBDyqAeNVkm7, -2.8419 address b, amount b
• outputs (min 1, max 2 if sent from a hive wallet) address x, amount x (destination address if sent from a hive wallet) address y, amount y (change address if sent from a hive wallet)
• transaction fee paid
• number of confirmations
• timestamp

I'd like to us to label (or somehow differentiate) all addresses owned by the wallet

[haustraliaer]

I've setup a basic modal for this now - but it's only got the ID, toAddress, amount and timestamp.

https://github.com/hivewallet/hive-js/commit/11c92efef98f2a974975e258e0d43aa00b5cf385

@weilu you'll need to show me how to retreive the detailed inputs/outputs, fees paid and confirmations from the API.

@jenbennings feel free to improve on the design of the modal content (especially once the other details are in there).

[weilu]

@haustraliaer I can dump the info on the page for ya. Can we work on this on a branch?

[haustraliaer]

Yep sounds good.

[haustraliaer]

This is done in it's basic form - moving to August milestone for more detail on transactions.

[weilu]

@haustraliaer @jenbennings Shall we differentiate external addresses from our own receive addresses and change addresses on the UI somehow?

[ghost]

Transaction detail implementation to be a feature of Hive 2.0.