Improvements on the earnings transaction overview

[kimmerin]

@buchen suggested in #3927 to add "expected earnings" to this widget in addition or instead of the new widget. I keep my opinion that my new widget is the best and there is no alternative ;-) adding the proposed function to this widget might be useful as well. But personally I think that to get something useful out of it, the current widget as it is has a couple of problems UX-wise that could be addressed while working on the new feature.

First of all: It takes way to much space. Here is a shrinked down version of the view as it shows up in my PP-file:

The widget needs the complete height of the window to show the first three months of the year so you start scrolling very soon within the year to see current numbers. There should be a way to collapse and expand single months (e.g. by clicking onto the month label). The initial presentation should also be configurable. If there is a way to distinguish between a widget that has been added already (i.e. the design is loaded from a file) or that is newly added to a dashboard, the default configuration for the former can be "expand all" and the for the latter "expand current month" so that existing dashboard designs stay the ay the user is used to it and newly added ones come with a useful default.

The entries per month should be sorted by alphabet and identical entries should be summed up and shown as a single entry. Currently it seems that they are sorted by account and then by date which leads to lots of confusion if you have the same securities in multiple accounts.

Concerning the new feature for "expected earnings", I'd say that on the month level this could be shown as a second amount next to the already shown amount, e.g. in round brackets and a (readable) gray colour to distinguish it from "real" amounts. A payment is considered to be expected if you've owned the security one day before the ex-dividend-date (this is a generic assumption because currently DividendEvent doesn't contain the record date) and will be calculated for the month, the payment date is located. If expected payments are shown should be configurable as well with it being deactive as a default.

[Sn1kk3r5]

First of all: It takes way to much space. Here is a shrinked down version of the view as it shows up in my PP-file:

Basically the same behavior as in the transaction overview widget. So in case collapse is possible, it would be useful to have it on both widgets.

The entries per month should be sorted by alphabet and identical entries should be summed up and shown as a single entry. Currently it seems that they are sorted by account and then by date which leads to lots of confusion if you have the same securities in multiple accounts.

I guess this is a philosophy question. Depending on your personal view on things. I for example like the order by date. Just because it makes life easier when double checking with external dividend calendars.

Auto-sum makes sense when users select “Gesamtportfolio". But wouldn't make it the only option, as users might want to have a combined or single view on one more security accounts, without looking at all.

Concerning the new feature for "expected earnings", I'd say that on the month level this could be shown as a second amount next to the already shown amount, e.g. in round brackets and a (readable) gray colour to distinguish it from "real" amounts.

Not sure if brackets are a proper way of displaying a future payment. Might depends on a tooltip.

A payment is considered to be expected if you've owned the security one day before the ex-dividend-date (this is a generic assumption because currently DividendEvent doesn't contain the record date) and will be calculated for the month, the payment date is located.

This sounds reasonable.

Cheers

[kimmerin]

First of all: It takes way to much space. Here is a shrinked down version of the view as it shows up in my PP-file:

Basically the same behavior as in the transaction overview widget.

Can you point me to the class name of that widget or are we actually talking about the same thing? The widget I'm discussing here is shown as "Übersicht der Transaktionen" if added to the dashboard.

So in case collapse is possible

That one actually was the easy part. It's been more complex to get the widget having different default values if they are loaded from a PP-file or newly added in an opened file.

The entries per month should be sorted by alphabet and identical entries should be summed up and shown as a single entry. Currently it seems that they are sorted by account and then by date which leads to lots of confusion if you have the same securities in multiple accounts.

I guess this is a philosophy question. Depending on your personal view on things. I for example like the order by date. Just because it makes life easier when double checking with external dividend calendars.

Auto-sum makes sense when users select “Gesamtportfolio". But wouldn't make it the only option, as users might want to have a combined or single view on one more security accounts, without looking at all.

The current behavior is confusing AF because it's sorted by account (without showing the account) and then by date, so your use case of double checking against an external calendar should be complicated already. Here is an example of a month as it shows up when having the same securities in more than one account:

AGNC, Europe Select Dividend and Annaly show up twice at the beginning, the middle and at the end of the list. So even keeping the sorting of the entries by date (or make it configurable), there still should be a grouping and summing up of earnings of the same share.

Concerning the new feature for "expected earnings", I'd say that on the month level this could be shown as a second amount next to the already shown amount, e.g. in round brackets and a (readable) gray colour to distinguish it from "real" amounts.

Not sure if brackets are a proper way of displaying a future payment. Might depends on a tooltip.

At least in western countries, the use of the letter 'e' is often used for "expected", so 1.234(e) might be another idea . Maybe this can be used alternatively (still using a different colour) but I'm not sure if it's done the same in asian countries and how to localize that.

Cheers, Lothar

[kimmerin]

@buchen I've implemented the ability to configure if details of all, none or the current month only should be shown. In case you plan to do a new release and you find this a useful addition for that release as well, I can create a PR for this individual change. Otherwise I'd continue without a PR and implement the grouping and the expected earnings, after we've agreed on the details in this issue.

[Sn1kk3r5]

Can you point me to the class name of that widget or are we actually talking about the same thing? The widget I'm discussing here is shown as "Übersicht der Transaktionen" if added to the dashboard.

Sorry for the confusion, we are talking about the same widget!

That one actually was the easy part. It's been more complex to get the widget having different default values if they are loaded from a PP-file or newly added in an opened file.

Copy that. But unfortunately, I'm not familiar with java. So I'm not much of a help here.

The current behavior is confusing AF because it's sorted by account (without showing the account) and then by date, so your use case of double checking against an external calendar should be complicated already. Here is an example of a month as it shows up when having the same securities in more than one account:

What you are saying is right. But when examine your screenshot, I can straight away tell which Stocks or ETF appear in more than one depot. And this is exactly what a like to have. A Bird view for everything what happened, but with the details of each depot. I agree seeing the Depot name would be helpful.

So taking your example from above.... your doubles are:

• AGNC
• Stoxx Europe selcted div.
• Annaly

Assuming you would sum up the dividends, would make it easier to have a first glance view. But would make it impossible to see Depot by Depot. But again, I would say this is a philosophical question, where no right or wrong exists. I just wanted to rise a hand for a different view on things, without saying ho's right or wrong.

At least in western countries, the use of the letter 'e' is often used for "expected", so 1.234(e) might be another idea . Maybe this can be used alternatively (still using a different colour) but I'm not sure if it's done the same in asian countries and how to localize that.

I agree about the usage of (e) within western countries. And there is no doubt most people with a basic knowledge should understand the meaning. But at the same time, we do see the tons of basic questions in the forum. That's why I raised my point. With the right standard field description, this should work, I guess. With regard to localization, it might be worth to think about making use of the direct translation of the word expected.

I guess the (e) works in German-speaking countries and English-speaking once, because we have the similar meaning, between erwartet and expected.

Cheers

[kimmerin]

Can you point me to the class name of that widget or are we actually talking about the same thing? The widget I'm discussing here is shown as "Übersicht der Transaktionen" if added to the dashboard.

Sorry for the confusion, we are talking about the same widget!

No problem. One less task ;-)

That one actually was the easy part. It's been more complex to get the widget having different default values if they are loaded from a PP-file or newly added in an opened file.

Copy that. But unfortunately, I'm not familiar with java. So I'm not much of a help here.

As said, I've already found a solution and it's checked in already (including yet another missing escaping of security names in labels leading to funny effects with names containing ampersands ;-). Java isn't the problem here BTW, it's the framework used for persisting the application's state I'm not familiar with.

[confusing UX]

What you are saying is right. But when examine your screenshot, I can straight away tell which Stocks or ETF appear in more than one depot. And this is exactly what a like to have. A Bird view for everything what happened, but with the details of each depot. I agree seeing the Depot name would be helpful.

Assuming you would sum up the dividends, would make it easier to have a first glance view. But would make it impossible to see Depot by Depot. But again, I would say this is a philosophical question, where no right or wrong exists. I just wanted to rise a hand for a different view on things, without saying ho's right or wrong.

The sorting is still puzzling. It's either non-deterministic (i.e. random) or by depot in descending alphabetical order. Maybe a compromise (I'd like to keep the number of configurable things to a necessary minimum): Group securities and show the sum of all earnings of that particular security and - as it's now possible with the month - make the entry expandable, i.e. when clicking on it, the details per depot are shown. That additional space would allow to show the depot-name (incl. logo) and the actual date the earning took place (allowing you to see if depots delay payment like it seems to happen with some if I followed some threads on PP correctly).

At least in western countries, the use of the letter 'e' is often used for "expected", so 1.234(e) might be another idea . Maybe this can be used alternatively (still using a different colour) but I'm not sure if it's done the same in asian countries and how to localize that.

I agree about the usage of (e) within western countries. And there is no doubt most people with a basic knowledge should understand the meaning. But at the same time, we do see the tons of basic questions in the forum. That's why I raised my point. With the right standard field description, this should work, I guess. With regard to localization, it might be worth to think about making use of the direct translation of the word expected.

Shall we open a thread in the PP-forum "over there" or is that something that the translation team "here" can answer? Maybe @buchen can tell me more here?

I guess the (e) works in German-speaking countries and English-speaking once, because we have the similar meaning, between erwartet and expected.

Other western languages might have other abbreviations but I assume that they all can be placed in round brackets after the amount. Question is: Is there something equivalent with asian languages so that this can be solved by entries in the language files or do we need more sophisticated logic to show the values correctly in all cases?

Thanks for the feedback and cheers, Lothar

[Sn1kk3r5]

As this is getting longer and longer, and I don't like the quote feature on github, I'll try it this way.

Regarding the available space and how to make best use of it. Did you ever consider to change the whole widget?

Currently it's like Jan, Feb,March where each month is using a lot of space. This leads to scrolling. You mentioned it and I understood the collapse feature will come... but how about changing the whole order of the widget... starting on top with Dec, Nov, Oct. this will just need a single line each month and the current month can take the left over space without scrolling. But while writing this I guess this would only be a workaround in case of collapsing wouldn't be possible at all.

Shall we open a thread in the PP-forum "over there" or is that something that the translation team "here" can answer? Maybe @buchen can tell me more here?

IIRC when a new label comes in, the developer does make use of deepl.com for a generic translation and it will be replace when a native speaker shows up to correct or adjust.

Regarding the localization, I will ask a Chinese colleague tomorrow if they do have a special symbol for it, or how it's been done in Asia.

Cheers

[kimmerin]

Regarding the available space and how to make best use of it. Did you ever consider to change the whole widget?

Not really for two reasons: Too much work for something that started as my "inner Monk" complaining and this widget is already used "out there" as part of a dashboard design. So people expect that design to stay the same after updating the application. If you change the whole thing, people will comlain. It's true, because there is an XKCD-comic about it:

Currently it's like Jan, Feb,March where each month is using a lot of space. This leads to scrolling. You mentioned it and I understood the collapse feature will come...

No PR has been created, yet but I assume that one would be accepted.

but how about changing the whole order of the widget... starting on top with Dec, Nov, Oct. this will just need a single line each month and the current month can take the left over space without scrolling

I'm not sure if a I can get a mental picture of a widget with that change but it sounds like at the end of the year, the widget would essentially show up the same as now just with reversed order of months.

Regarding the localization, I will ask a Chinese colleague tomorrow if they do have a special symbol for it, or how it's been done in Asia.

That would be great, thank you. I'm in lack of Asians "here" ;-)

Cheers, Lothar

[Sn1kk3r5]

@kimmerin

I fear you missunderstood my proposal. As pics say more than 1000 words.. Here is what I ment: Left view is the current right view my brain dump :-P

The Advance here is, the current month is always in the middle of the screen and scrolling isn't needed at all. Until you are in the 3rd quarter of the year and like to see January.

I admit, a collapse feature would work the best way, and if you find a nice place for the depot name (or maybe not the name but an indicator, to safe some space)

Regarding Asia and (e) we need to wait for tomorrow, but I'll get back to you!

Cheers

[Sn1kk3r5]

Hi @kimmerin,

as promised. I talked to my Chinese colleagues. Unfortunately, the Chinese language mostly does not work with short terms or shortcuts. I guess this is a common standard for symbol based language…. Nevertheless, a future dividend payment is called: 预期股息 as this is way longer than the western (e) I have no idea if this still would fit. It may depend on a try run.

Hope that helps.

Cheers

[kimmerin]

Here is what I ment: Left view is the current right view my brain dump :-P

Thanks. This is a significant change of behavior which will very likely lead to complaints by users who are surprised by this and you will still end up with the scroll-fest at the end of the year (but you're right that the actual need to scroll would occur lesser). Still I think this is a too big change for too less gain and a lot of PITAs discussing the change with enraged users or adding yet another configuration option to the widget.

Nevertheless, a future dividend payment is called: 预期股息 as this is way longer than the western (e) I have no idea if this still would fit. It may depend on a try run.

(e) doesn't mean "future dividend" but that something is expected. In this particular case an earning like a dividend. But you see this with other figures as well, e.g. a company's expected revenue, costs, etc. So maybe you can ask again if there is something similar. So - using deepl for translating "dividend" (no future) - something like this:

红利: EUR 123.45(e)

[Sn1kk3r5]

(e) doesn't mean "future dividend" but that something is expected. In this particular case an earning like a dividend. But you see this with other figures as well, e.g. a company's expected revenue, costs, etc. So maybe you can ask again if there is something similar. So - using deepl for translating "dividend" (no future) - something like this:

红利: EUR 123.45(e)

Gifted stock in Chinese... not bad :-)

OK back to topic. When we were talking, we went through a couple of famous Asian financial portals. Based on what I learned is, the do structure their content completely different from western pages does.

And the next thing is, as I wrote above, Chinese language almost never use a short term as they do have symbols as represents. Some symbols do stand for a whole sentence in western language. So when ever we were looking on forecast data they were using 预报 (Yùbào)

[Sn1kk3r5]

Hi @kimmerin

may I ask something not related to this topic? I hope you don't mind. Can you tell me how to start PP out of eclipse in a different language then German. I know about the NL en_EN Parameter, which works on the standard installation. But I have no idea how do to the same for PP running out of eclipse.

Background, I have changes with requires translation. And I'd like to check them before committing my changes.

Thanks in advance! Cheers

[kimmerin]

Can you tell me how to start PP out of eclipse in a different language then German. I know about the NL en_EN Parameter, which works on the standard installation.

I haven't tried it but in portfolio.app/eclipse you can edit the file launches.lc where there are "vm-argument"-entries. This should allow you to set the system properties for language and locale.

[Sn1kk3r5]

vm-argument"

I tried this. And also for Program. In addition I tried the given variable taget.NL including parameter en_EN. But nothing worked.

@buchen do you have any idea?

I would like to check my language additions before I sending a SR.

Cheers