[24] Tables Rewrite - Dashboard

[wmbutler]

The idea behind a tables rewrite is to change the look without worrying too much about functionality. This amounts to a facelift while establishing some best practices for the future. The wallet has a somewhat haphazard approach to accessing certain features. Some items are in a top menu and others are on a side menu. Side menus are notorious for wasting horizontal space. I think they should go away ultimately, but don't want to change so much at once that it confuses users. With that in mind, I'm going to submit a table concept for the Overview page. As you can see, I've suggested that we call it Dashboard instead.

Rather than the user scrolling down and accessing other menus to get to other areas, I've created pills at the top. Areas that contain balance detail also display the total balances in the pill for a glance.

You should notice that the functionality of the table is identical but instead of clickable text, we have meaningful icons. I have also created separate columns for symbols and quantities so our data lines up in a more pleasing way.

As you view this, realize that the top and side menus aren't visible in my mockup. This table would be displayed in place of:

As we get closer to consensus, I also need to propose a light themed version of this.

[wmbutler]

Updated the Margin positions UX to allow for all the math to add up. Of note:

• [x] renamed debt column to asset column
• [x] moved debt column to allow for a value calculation (per user specified currency)
• [x] Included a value column that should agree for both downward math and across math for preferred currency

[svk31]

Here's a testnet example with an account holding margin positions backed by something other than TEST (the core asset):

[svk31]

Order expiration just takes so much space I'm opposed to including it.

The 100% height on the black background requires a lot of messing around with css, I wasn't able to figure it out and not sure it's worth it.

[wmbutler]

• [ ] Font consistency. Remove the narrow font from the TH

[wmbutler]

• [x] Add price column to Portfolio. Use whatever number you use to derive the value column. (i.e. Qty * Price = Value)
• [x] Can we change "Unknown value" to "NA" for brevity throughout. Otherwise maybe "--"? I really like -- better.

[wmbutler]

• [x] odd gap in my portfolio between bitUSD and open.BTC. Not sure what causes this.

[wmbutler]

• [x] Excessive right padding in this dropdown, Activity tab
• [x] Reminder: move this to the TH replacing OPERATION text

[svk31]

No idea what you mean by narrow fonts in the header.

I used to have n/a for unknown prices, but nobody understood what that meant so I changed it..

The gap in the portfolio is between assets you actually have and the default list of assets that are shown so you can easily buy or trade them, they're shortcuts basically.

[wmbutler]

• [x] The Narrow font is Roboto Condensed. Let's just use Roboto.
• [x] Can we try -- ? I'll defend the decision.
• [x] Would you be ok removing the gap? From what I can tell it doesn't really serve any functional purpose and it throws off the consistency of the row height.

I know it feels like I'm being really picky at this point, but it's my hope that we can set as many standards now as possible on these tables. Please increase the hours on this items to reflect your time worked.

[wmbutler]

• [x] We need a price on the Portfolio page. Qty * Price = Value. If we have a value and a qty, it's really important that we include the price. This isn't really an optional field when a user is looking at their total assets.

[wmbutler]

• [x] We have the call price listed but not the price on the margin screen. I agree we have the ratio, but it makes sense to include the price as well for the user. This would also allow the user to validate the ratio value.

[wmbutler]

• [ ] The sort order on the open orders listing appears arbitrary. I think we need to pick something that will remain static if the user chooses to toggle the price. Either the order placement date or expiration date would suffice. I still feel that a visible date field is important here but at a minimum, we should let the default sort order be by date. I don't know whether it should be ascending or descending. I'd imagine this will eventually be a user selectable value.

[svk31]

The sort order is by price, which is the only sorting that makes sense.

[wmbutler]

Hrmmm, open orders being sorted on price? I would think grouped by market and then date makes more sense. The sort order should not change when switching the pricing pair. I hope you take some time to reconsider your opinion here.

[svk31]

By markets first, then price.

[wmbutler]

My fear is that when someone inverts the price, they will lose whatever row they might have been on and may end up canceling the wrong order.

[svk31]

The market direction is persistent and consistent with your selection everywhere else, so I don't see why anyone would ever switch that direction more than once anyway.

[wmbutler]

• [x] Total summary should be aligned with Value column

[svk31]

Sorting by price makes it look similar to a vertical orderbook, which at least to me makes a lot of sense..

[wmbutler]

• [x] Anytime displayed currency is the same as the bitasset, we should display a 1 for the price.

[wmbutler]

• [x] If user has any potential margin call issues, match color of dollar value in header to most vulnerable position.

Current

Expected

[svk31]

I think this is about ready now, it's also taken a lot more time than the original estimate, at least 3 full days or 24 hours.

[wmbutler]

I figured!

[tbone-bts]

In a portfolio view, it makes the most sense for your largest positions to be at the top, smallest at the bottom. So sorting descending by Value (not by Price) would really be best here.

Sorting by price makes it look similar to a vertical orderbook, which at least to me makes a lot of sense..

[wmbutler]

@tbone-bts we are cutting off the features for now. This falls under sort order. Open a separate issue for allowing sortby. Thanks.

[tbone-bts]

I agree that allowing sortby is a different issue. But I was talking about the default sort order. @svk suggested default sort order should be by Price bc it's similar to order book...and I was pointing out that in a portfolio it should be sorted descending by Value of the holding.

[svk31]

We were talking about open orders, not the portfolio.

I agree it makes sense to sort the portfolio by value of the holdings, I'll have a look to see how difficult it would be to implement.

[tbone-bts]

Ah ok, your comment was directly after a post with an image of the Portfolio table. Threw me off. But thanks for clarifying!

[svk31]

Merged