search

bitfocus / companion

Bitfocus Companion enables the reasonably priced Elgato Stream Deck and other controllers to be a professional shotbox surface for an increasing amount of different presentation switchers, video playback software and broadcast equipment.
http://bitfocus.io/companion
Other
1.62k stars 505 forks source link

[BUG] Improvements / issues with page management #3126

Open dnmeid opened 2 weeks ago

dnmeid commented 2 weeks ago

Is this a bug in companion itself or a module?

Is there an existing issue for this?

Describe the bug

I had the chance to play a little bit with the reorderable pages and it seems not production ready yet. There are a few things I like to mention:

  1. Whenever I drag a page to a new location, the pages are swapped one by one. This takes a considerable time and it does not happen on dropping the page at a nwe location but on the go. So when I drag from position 1 to position 5 I pass positions 2,3,4 and all these are individual reorders sent to the server. When I do drag a little bit up and down, the core takes much longer to follow. I easily can manage to make my GUI unresponsive for quite a long time and then see all the moves I made later. -> The GUI should stay responsive during drag, only the final result of the drag should be promoted
  2. I think it would be more convenient to be able to edit page names inline in the list. Then the Edit button and the whole modal can dissapear. The current workflow is: clicking on edit button, selecting the current page name, replacing with new text, clicking save. With inline editing we can save two clicks and more important a modal. This would also be more in line with the usual Companion workflow where you just edit a value.
  3. Also the page add modal is quite annoying and disrupts the workflow unnecessarily. It would be much better to just add a page without any modal.
  4. For convenience it would be better to change the "add above" buttons to "add below" buttons. The final append button then would be a "insert at top" button and would also be shown on top of the list. Then you easily can click a button multiple times without having to move the mouse or scroll the list.
  5. In old UX so far a page didn't had a name by default. The word "PAGE" was only the placeholder on the page name textbox, dissapearing as soon as you started typing. I think we should keep this UX, that a page by default only has a position and is not assigned a name automatically. Noone want's to have all the pages named "PAGE" or "New page". If you care for page names, you want to name your pages individually and then you don't want to have to remove the word "PAGE" or "New page" every time. (Btw why is the first page named PAGE and all added pages New page?). Also when importing a page without a name, it should not automatically be changed to PAGE, but just stay empty.
  6. If you want to import a single page from a stored configuration, you should be offered all the existing pages in the configuration. Currently I can only choose the pages up to the index of the pages I have added. E.g. If I have added three pages, I can only import pages 1, 2 and 3, even if there are more pages in the stored file.

Steps To Reproduce

No response

Expected Behavior

No response

Environment (please complete the following information)

Additional context

No response

Julusian commented 2 weeks ago

1) This behaviour is consistent with how things behave elsewhere. But yeah this is much costlier to do than dragging actions around so would make sense to defer

2) It's using a modal that predates this list, its the same one that has been around for a while in the button view. I'm not opposed to editing it inline though. I have been expecting there to be more things added to that modal over time, so I don't want to remove it entirely.

3) See the discussion https://github.com/bitfocus/companion/pull/2689#issuecomment-1897493024 for why this is a modal (TLDR is to allow adding multiple pages at the same point easily)

4) I'm not opposed to changing that

5) I decided to start nudging users to give their pages a name. Of course you don't have to do it, but I think it is a good idea to prompt users to do it, both for their own sanity and so that we can provide a useful list of pages. Considering that pages can now be moved around, having none of them named makes it incredibly hard to find anything.
Pages always had a name of PAGE unless the user changed it. In a couple of places this value was interpreted as being the default so was handled specially (I don't remember what of that logic was changed)

6) It is supposed to be showing them all, and I'm pretty sure was working at some point

dnmeid commented 2 weeks ago

  1. Adding many pages fast is absolutely something we want to have. But as far as I see it the modal doesn't make it any faster. Overall it makes it slower. Assume you want to add three pages. With modal you have to click on the + to open modal, click two times on + in modal, click on add = 4 clicks. Without modal you click three times on a + = 3 clicks. Additionally with the modal you need to reposition your mouse at least two times, without a modal zero times. When you want to add only one page there are 2 clicks with modal and one click without. So in any case the modal doesn't give any benefit. Especially if the + is changed to "add below" there is no mouse repositioning needed between clicks and that will be a lot faster, more intuitive and generally should modals be avoided. The current modal only has an advantage if you want to add AND name pages because you are saving the click on the rename button. But this advantage is lost with the linline name editing like I propose in 2.

  3. I agree that page names are useful and especially if you can reorder the pages it helps a lot if you have an identifier. But giving any page a default name doesn't help to tackle this. Again I find that annoying, especially because now you have to actively remove the default name and replace it with a useful name. That just doesn't make sense. I think it would be more encouraging to have the inline name editing and show a placeholder like "Name this page...". As a placeholder this text would show up in grey and only if the field is empty and out of focus. Also in dropdowns like "jump to page", there is absolutely no advantage of showing "1 PAGE", "2 PAGE", "3 PAGE"... over "1", "2", "3"... And no, pages did not always had a name of PAGE. Initially pages only had a number and the possibility to give them a name had been introduced later. By that time the page name entry used PAGE as a placeholder. The special treatment is the page number button, it shows PAGE + page number if the page doesn't have a name or the page name is PAGE (because we recoginzed that there was no way of removing a page name and so many people wanted to go back to default by reentering the placeholder text) and it shows the page name if there is a diferent name.