Customizable tab system

[rafaelfcponde]

This is more of a suggestion than an issue, and I believe it can be quite challenging to pull off. However, I believe it can make the app stand out among the other collection manager apps.

Instead of the "TDI system" that's being used today, I'm thinking of making the app as like a big white board in which you can bring multiple windows, to maximize user customization (and boost practicality).

It would work something like the Fruity Loops UI: when you open the app, it would be empty, with just the superior row for tab selection and other options. From there, you could prompt the app to open windows specifically for the things you want to work on (a Deck window, a Collection window, a Search window, a Selected Card Details window, etc).
Those windows would be each scalable and customizable on their own (this way, the user could choose how he wants his interface to look like, both to enhance aesthetics and boost usability).
The tabs would be used to manage multiple "white boards".

[NikolayXHD]

Thank you for explaining your idea in such great details. Suggestions are a valid and welcome type of issue.

I can see how Whiteboard approach can be useful by example of Forge

As a sidenote, it requires scalable card images (which you already pointed in #2 which I separated to #5) in order to efficiently display cards in smaller panels

Now, I agree with your estimation that of that being

quite challenging to pull off

So, to justify the effort in particular case of Mtgdb.Gui, there have to be examples of layouts (filled Whiteboards) with following properties:

• It greatly improves convenience for doing some task over the current UI
• The improvement cannot be achived by modifying the current non-customizable UI without making it worse for other important tasks.

I am talking about specific Mtgdb.Gui layout examples for a reason. While generally speaking Whiteboard approach has its benefits, it should not be assumed those benefits can universally improve any program.

Specific layout examples may show that keeping a single layout may not be the best long-term option specifically for Mtgdb.Gui.

Provided such examples are given, there is still an option of giving several non-customizable layouts for users to choose from. Such an approach would have advantages over customizable UI:

• They are available to users out-of-the-box, many users avoid trial-and-error process of creating the layout
• All users share the benefits while these layouts are being improved based on users feedback, which also comes from many users instead of the single person who has created a layout for himself.

So there has to be a wide family of layouts that are simultaneously

1. Good enogh to significantly improve some user workflows to be worth creating.
2. Not good enough to make them available to everyone as a named pre-set layout.
3. Given the difficulty of task, the advantages must be specific, clear and significant to prefere turning the effort to it over developing other features.

Now as far as I see point 3. directly contradicts point 2. which makes implementing customizable layout a wrong choise unless I am wrong myself with my arguments.

[NikolayXHD]

Versions 3.2.0.0 and 3.2.1.0 introduced Multi-window support with window position preserving between restarts and ability to drag-n-drop cards and tabs between windows.

Combined with previously existing possibilites to hide filter panels and deck area, these give you a degree of control over your screen layout comparable to what Whiteboard approach would give.