New UI Design proposal

[usolved]

I asked in issue https://github.com/buchen/portfolio/issues/1858 that I like to make a suggestion for a new UI design. As @buchen said it might be not that easy to actually implement a more modern look because of Eclipse SWT. But I wanted to give it a shot anyway.

There are some other closed source / commercial tools with similar functionality but would be cool if an open source tool would also step up the design game a little bit :).

New UI / Example for portfolio

Figma link to the project (read only mode)

So what are the ideas behind this?

Generally speaking I concentrated mostly on the UI and not the UX part. And it's also not complete (like showing the opened *.xml file). Things I addressed:

1. New navigation menu The current one is already really nice but I wanted to bring in the macOS style to feel more at home like the other apps. Also it gives more focus to the actual entries and not the headlines.

2. Add new portfolio button placed differently When I first used the application I was confused to have so many actions behind the plus icon on the right. I think it's better to see clearly how to add a new portfolio separated from the other actions.

3. More spacing in table rows It's easier to read the table entries with a little more space added. On the contra side you have less rows on one screen but improved readability was more important to me that a little bit more scrolling.

4. Added color scheme I don't know if you have a primary brand color (the buttons on the website are orange) so I used the blue tone from the logo because it's more subtile than the orange or green for this purpose.

5. Actions menu Depending on the screen you're at you could show the mostly used actions directly (like buy and sell) and have the three dots for more actions (same as right click on the row). The advantage for the three dots is that you know without guessing that you can do some actions on the row.

6. Show sub headline from selected row Depending on the screen it helps to have context by adding a sub headline (e.g. Comdirect). So when you look at the data from the selected entry you easily can make sure it's the right one.

7. Show important information on top Like profit and loss in this example. That depends of course on the screen. There might be screens where you don't need highlighted information. In this example it's nice to have some overall information.

8. Tab navigation Just different style and matches more the macOS style.

9. Vertical line on the left Just a visual clue to signal that all the content belongs to the selected entry above and hold it more in place.

10. Get rid of table rows without content When rows are not filled with entries don't show them. This will let the design more breath because of the white / negative space.

[chrisaut]

I've been thinking about this too for a while, PP does not look modern or sleek :-(

I doubt swt is capable of the sort of UI, but I do not know. Maybe some things can be made to, with workarounds and tricks, but It'll probably never be able to do things like fluent animations and such. A while ago I looked a bit into options to maybe have the UI layer as an electron app, while keeping a java backend, for example

But it's a huge, huge undertaking, even if everyone agreed to such an approach. I would even say it's so big that one might as well go fully JS and do a complete reimplementation at that point. I kind of doubt anyone has the time or motivation for something like that though

[networxnet]

" I wanted to bring in the macOS style to feel more at home like the other apps"

Your draft looks nice @usolved, but don't forget macOS style feels only more "home" for mac users, but the mass uses WIN. So navigation and UI should at first be oriented to WIN10 to be most intuitive for most users.

[usolved]

Yes you are right.

An approach could also be to do it like Slack, Spotify, MS Teams, etc. they look more or less the same on every platform but don't have native OS menu structures, buttons, etc. for example.

So this is just a first draft to get a discussion started and to see where the limit are with the SWT :).

[tsohst]

Even as a windows user I can say this looks great, would be a huge upgrade which can compete with the TresorOne app.

[Shorty68DE]

That is a great draft!!!

For example bothers me in PP that you have to make columns extra wide in order to be able to read column headings completely. So I do not really love to work with PP in the current UI.

[buchen]

Really great design draft - @usolved - thanks for putting the time into this.

I wish I could (easily) build it that way...

Let's quickly talk about my current restriction:

• PP is coded in Java and it uses the SWT. SWT "wraps" Java code around the native platform OS widgets. Therefore I have to develop the UI only once, but it uses the natives widgets on each platform: Windows, macOS, and Linux
• This limits my code more or less to standard widgets (or whatever customizing SWT has build into it - dark mode). For example, I am not aware that I can extend the sidebar right to the top of the window.
• Much bigger are the limitations on the table and tree widgets. For example, on Linux the width of the last column is always extended to the end of the window (on other platform it is not). I immediately noticed that the design proposal does a similar thing - but with some "breathing space" if the window size changes. Another example with tables: I can either have the "native" background color of rows or none at all. On macOS that means even and odd columns are rendered differently, on Windows it means they have the same background color but a tiny line is drawn between the lines. I also like the idea that the table lines are not drawn if they contain no data - I have to check what is possible in SWT.

Before I look at what we can do, let me comment on the alternatives - hinted to by @chrisaut:

A while ago I looked a bit into options to maybe have the UI layer as an electron app, while keeping a java backend

I have to admit that I envy the Electron project for some time. You can actually build a macOS app store-compliant app (PP is signed, but not compliant and I could never publish it there). And it is amazing what kind of graphic libraries have been created for JavaScript - the Java ecosystem has only a limited fraction of those.

The example - electron frontend with java backend - I have also seen in the past. The issue I have with this approach is that I would have to go "all in" right away. I cannot embed existing UIs into Electron and then - step by step - port to the desired technology. The Electron app would only be viable once the bulk of the UI has been re-implemented. And that is a huge effort considering the past 9 years of this project.

With the lastest SWT releases, there is the possibility to embed Chromium into SWT widgets. I have not tried it yet, but my thinking is: this way one could "convert" views one by one to HTML/JavaScript and maybe, maybe eventually move to Electron fully.

You might ask: the pie charts are already displayed in HTML/JavaScript (using D3.js). Why not extend it? Well, the current browser widget is always wrapping the native browser that the user has installed (if he has it installed) - for example on Windows only the Internet Explorer and on macOS Safari. Therefore I have limited control to what features are available. Plus: it is a pain to develop as there is no console, no debugger, no source code view, no logging. That is supposed to be better with Chromium - plus we would have exactly one browser version to test PP against.

Let's get back to the design proposal:

1. New navigation menu

I like it - that can be implemented at least within the current boundaries of the sidebar

2. Add new portfolio button placed differently

Nice idea. The create actions would move next to the heading, the configuration/filter/viewing actions stay on the left side.

3. More spacing in table rows

As outline above, SWT allows little control on the tables/trees itself. At the moment, PP remembers the order of columns and the width as configured (via mouse) by the user.

4. Added color scheme

Using the blue icons (and text) makes is visually much more pleasing.

5. Actions menu

Lots of actions are in the context menu and, of course, unless you try to right click a table row, you don't know. I am a little hesitant to add buttons to the tables. Yes, for short rows with little data, it is easy. But there are also a lot of tables where there are a lot of columns. Then having the "primary actions" always in the table also uses up a lot of screen real estate. I guess we have to try. But I get the intention.

6. Show sub headline from selected row
7. Show important information on top
8. Tab navigation
9. Vertical line on the left

Both absolutely valid ideas. I make sense for these "split views" with master-detail pains.

I just noticed that it is particularly strange for "securities". The name of the security is repeated, but only within the first tab (the price chart). Plus: most of the time, we should be able to make room next to the tabs. I would think the style of the tabs could work on all platforms. I do not know for sure, but I think it is possible to provide an own implementation for rendering the tabs.

10. Get rid of table rows without content

I have to check. Valid feedback.

A couple more thoughts - I am interested in your feedback:

• Your design proposal has no file name or whatsoever - you think that is not needed?
• Today, PP is a "multi-document" application. The top tabs are "Welcome", "Error protocol" and the files. Personally, I usually have a lot of files open to test various situations. But I have no idea how many folks are actually using this. Do you propose to a go to a single windows = single file approach?

[usolved]

Thanks for taking the time to give such detailed feedback and all the thoughts that went into it :).

Some things on this first draft might also need some user testing or more adjustments. As a designer I can think of some stuff beforehand but when you see actual users work with an app, you may just see the shortcomings of a proposal later on.

Your design proposal has no file name or whatsoever - you think that is not needed?

For my personal use case I only created one xml file where I have all by portfolios and stocks. I closed the tabs "welcome" and "error protocol" (to be honest, since I've used this app for quite some time I didn't remember these tabs where even there).

So for me it would be totally fine to open my xml via the file > open dialog any maybe see in the window title bar which one is currently opened.

Another idea could be to have a brand new start screen within the app (with overall dashboard with some basic stats, welcome, wizard how to start, what's new, switch files, social media links, ...).

But I'm also looking forward to feedback from other users. In such cases an "evil" usage statistic would help how ppl use the multi document function ;).

On a side note: I'm really thankful for all your time and effort you put into this great application over such a long time :).

[maku]

@buchen To be curious, would it be possible that the current app acts as a server with some kind of a rest backend and delivers also some kind of SPA which acts then as frontend. From my point of view this would be an interesting approach...

[chrisaut]

A couple more thoughts - I am interested in your feedback:

• Your design proposal has no file name or whatsoever - you think that is not needed?

The only time I've ever found it useful is when debugging. My "real" file is literally called portfolio.portfolio. I would guess, although I don't know, that the vast majority of users only ever work with one file and even if they have 2, 1 for each family member or something, I doubt anyone would be confused about which file is open ATM. But I believe we can easily find a way to display it without compromising visuals, if there is any doubt.

• Today, PP is a "multi-document" application. The top tabs are "Welcome", "Error protocol" and the files. Personally, I usually have a lot of files open to test various situations. But I have no idea how many folks are actually using this. Do you propose to a go to a single windows = single file approach?

As above, for me, the only time I ever have more than 1 open is while debugging. Or if I want to try something, like a large import, I make a copy of the file and try it there first. The welcome page I never use, it could easily be made a splashscreen though, and error protocol probably shouldn't be a tab comparable to a document, that always seemed a bit weird to me. Like usolved I too would be perfectly fine if each file were it's own window.

[dylan09]

A few thoughts about your proposal. Looks vey nice and modern. And its very clear.

But as a "heavy" user I also see some drawbacks:

• Almost every time I have opened 2 or 3 files at the same time. So single document design is a step back for me.
• I have a lot of accounts (around 20) and a lot of securities (more than 200) in my biggest portfolio. Thats the reason I would stay for the current design without much space between table lines and columns. Or I need a much bigger display to get the same information to the screen. 😞
• And on the securities view I have views with up to 15 columns. So every pixel of screen space is needed to get everything visible on my 16" notebook screen.

Even though I really like your design, I would like to keep the tables as they are.

[debegr92]

@buchen To be curious, would it be possible that the current app acts as a server with some kind of a rest backend and delivers also some kind of SPA which acts then as frontend. From my point of view this would be an interesting approach...

This sound really very interesting... Maybe there is an easy way to implement a GraphQL API and a background service, which handles all the functions and file access. With this API all platforms can be easily accessed. https://www.graphql-java.com/tutorials/getting-started-with-spring-boot/ https://graphql.org/code/#java-kotlin-server Maybe this can be discussed in another feature.

[buchen]

@buchen To be curious, would it be possible that the current app acts as a server with some kind of a rest backend and delivers also some kind of SPA which acts then as frontend.

To my understanding, the approach with an Electron frontend with a Java backend mentioned by @chrisaut would be exactly such an approach. The rest is source code, of course, and the app could act as a server. I "just" has to be implemented 😉

Maybe there is an easy way to implement a GraphQL API and a background service, which handles all the functions and file access.

@debegr92 PP Java backend would implement GraphQL, but what is the UI to display that?

[maku]

@buchen I do not agree... Using electron produces a rather fat desktop application (which under the hood is using chromium to be able to render html / js etc.). The other approach would make it possible to run the app as kind of server. And a real web app running in a browser would be able to communicate with this "server" for data handling (either via rest or with grapqhl). So you would also be able to have your data on several devices (e.g. also mobile) Of course than it would also possible to create "native" mobile apps if someone wants that

[debegr92]

@debegr92 PP Java backend would implement GraphQL, but what is the UI to display that?

I like the idea of a fast and responsive web application with Node.js and React. So we can address all platforms at the same time without struggeling with the native widgets.

[maku]

@buchen to the second question. The UI could be everything. Everybody would be able to connect to the "server" . But of course it would be a good idea to develop a "default" web app. It is simply a split of the application into a backend and a frontend part where the backend part remains Java and the frontend part can be done in any technology...

[maku]

@debegr92 of course the tech stack for the frontend is "debatable" :-) I for my part like svelte. But there are many strong frameworks out there.... (vue etc.)

[polymeris]

I'm just a recent user, so I don't perhaps don't understand all the complexity and implications, but the idea of having the application serve some kind of web API sounds really cool to me. Not only would it allow to feed a Web/Mobile/Electron based UI, but also extend the automation options. E.g. I could write a script that downloads and parses the horribly formatted reports from my broker and calls the API to update transactions and quotes. It even opens the door for e.g. a cloud-based version of PP if somebody really wanted something like that.

I'd lean towards something REST-y, since for better or worse it's still the standard and the tooling is so much more mature than e.g. GraphQL, but that's an implementation detail.

[Pnda87]

Great work! I really like your UI proposal.

For my side, I do use 2 different portfolio files at the same time. However, I dont have a strong opinion whether this possibility should remain or not. Maybe multiple instances of PP would do the thing, too?

separating backend and frontend would be appealing, although I see the huge effort needed for that undertaking...

[usolved]

Really great and interesting discussion going on here :).

This could be really pushing PP forward. But since (as far as I know) buchen is the primary maintainer it might be a really big challenge and really time consuming to build a whole new technical stack. Maybe we need a donation system for this project? ;)

@buchen You've said in the logo proposal thread that you're experimenting with some UI things. If you like, feel free to post tests or work in progress screenshots. Because maybe some things might not work out as originally thought as some feedback in this thread tells. Or maybe we can improve on some ideas.

I'll regularly check this thread and if at any point we are more flexible with the UI design because of new stacks I'll see how I or others can contribute to this project with designs.

[buchen]

With #2085 I have embedded Jetty and provide one endpoint to list transactions. Feedback welcome.

[raDiesle]

Hello, I think we should first think about overall Strategy related to architecture: Do we want to enforce the requirement to run a server? Who will pay for it? How people want to use the new ui primarily?

To throw in another idea: how about a storage such as google drive, which will just synch files between current and new ui?

I suggest to go for a web based ui, as it's easier to maintain, integrate and find developers. Gwt can be an option to consider, so java developers are not lost completely.

[oxisto]

@usolved I have started implementing this in svelte using the branch which uses the REST API in #2085. Any interest in collaborating on this effort?

[usolved]

@oxisto Cool :) In which ways were you thoughts to collaborate on this?

[oxisto]

@oxisto Cool :) In which ways were you thoughts to collaborate on this?

That depends of course on your motivation, time, interest and "technical skills" :)

In order to progress the following steps are need

• The REST API needs further expansion, currently I have basic read-only endpoints for listing securities, accounts, portfolios and their security positions, including very basic performance values (purchase price and profit/loss)
• The one view you designed was a pretty good start, but we need to expand it to other views as well and design them, not sure in which priority. Having the additional views on figma will probably help.
• Currently the figma views are basically placed directly per x/y coordinates. I am not an expert on figma but is it possible to place the components relative to each other, e.g., using the actual CSS padding etc? That might make it easer to translate it into bootstrap/sveltestrap css code.
• The views need to be translated into actual svelte templates. This includes a) code that fetches it from the server using typescript b) the actual CSS code. I started with your portfolio asset view and the code can be found in this repository: http://github.com/oxisto/portfolio-ui
• Probably the css code that I wrote until now needs some more refinement, it is not yet matching all the fonts and spacing, etc. that you have

[oxisto]

To give you an idea about the current state. This is a screenshot of the current state of the UI with "real" data coming out of Portfolio Performance using the REST API. The data itself is fake though ;)

[usolved]

First of all great job. It's really nice to see an idea coming to life :).

That depends of course on your motivation, time, interest and "technical skills" :)

Interest/Motivation is definitely there but beforehand it's sometimes not that easy commit exactly to a certain amount of time on OSS projects. I'd like to contribute but want to focus on the design part though (and hopefully others might join to support on the coding side).

• The one view you designed was a pretty good start, but we need to expand it to other views as well and design them, not sure in which priority. Having the additional views on figma will probably help.

Yes, we need mockups at least for all base elements (nav, table, font styles, icons, tabs, highlights, menus, forms, etc.) including different base layouts. Once this is established (like a pattern library) it's easier to build new sections to always have a good reference.

• Currently the figma views are basically placed directly per x/y coordinates. I am not an expert on figma but is it possible to place the components relative to each other, e.g., using the actual CSS padding etc? That might make it easer to translate it into bootstrap/sveltestrap css code.

Hm... I'm not sure if this is possible. But at least on the "Inspect" view you can see the padding within elements or elements next to each other. But in general I don't think it needs to be pixel perfect anyway. If we like to strife for a browser/web app view it should be responsive and the placements of the elements could be set to a grid system (like a 16 grid to have more flexibility). Maybe even that responsive to provide a mobile view.

Would be also nice to have the "rem" values directly on the Figma file instead of the pixels. So for example setting the body base unit to 16px and all other elements are relative to that 16px. But as far as I know this isn't supported.

• Probably the css code that I wrote until now needs some more refinement, it is not yet matching all the fonts and spacing, etc. that you have

I think that's not a big deal right now since the design needs to be refined as well. Since the design of the first draft was oriented to a macOS style (like the nav) I'm thinking - since we are more flexible now with the whole toolkit that the web has to offer - to come up with an updated design that could diverse even more from the original one.

[kazyka]

So what is the status on this?