Quick Connect redesign for multi-protocol connectors

[axpnet]

This thread is for designing the Quick Connect (Add / Edit Server) layout, starting with the connectors that expose more than one protocol for the same account.

It grew out of a bug report, #215, where @EhudKirsh asked to switch a saved profile between its protocols (Native API, WebDAV, S3) without losing credentials, the favourite star or the storage quota. All of that is fixed and shipped. Along the way Ehud sketched a much better Quick Connect layout and a clear line of thinking behind it, and that design work does not belong in a bug thread, so I am moving it here where it can have proper mockups and a real back and forth.

Credit where it is due: the core idea, and the first mock, are Ehud's. In his words the goal is to need only one profile per online account, and to switch protocols from inside that one profile, instead of keeping one remote per protocol like rclone does. His Koofr sketch reorganised the form around that idea, and it is the starting point for this thread.

What he proposed, in short:

• Group fields by relationship, optional vs required, paths together, protocol related together, advanced (Wrappers / Overlays) collapsed at the bottom.
• Put the protocol selector as a divider: the fields above it are the ones that do not change with the protocol, the fields below it are the ones that do. The selector's position then tells you, with no extra text, which fields are shared and which are protocol specific.
• Keep fields that appear and disappear (Endpoint URL, Port) below everything else so switching protocol never pushes other fields around.
• Move the profile icon up next to the name, pick it like in Google Docs or Microsoft To Do.
• Rename "Connection name" to "Profile Name", drop the floppy icon, shorten the field.
• One single Save button, no x, no in-form duplicate, no Save-as-new. Duplicating a profile is done from the My Servers page.
• A new Overlays Remote Path field inside the collapsible Wrappers / Overlays section, defaulting to the Remote Path and constrained to be that path or a descendant of it, never an ancestor or sibling.
• The same layout generalises to every Quick Connect page, including modernising the OAuth pages so they too get Overlays, custom icons, and so on. The five complicated ones (Filen, MEGA, OpenDrive, FileLu, 4shared) get their own treatment because of privacy settings and local-server modes.

A first piece has already shipped in v4.1.0: every connector now uses the same two-column layout, the OAuth pages included, with the profile icon next to the name and the Wrappers / Overlays section (the transparent crypt overlay) open by default. Here is the pCloud OAuth page.

One important scope note, because it is the natural worry with a "one profile, many protocols" UX. This is a GUI reorganisation only. Under the hood each protocol stays its own independent profile record, with its own id and its own credential in the vault, and it stays individually selectable in export and import. The single cleaner form is a nicer way to drive records that already exist, it does not merge or couple your profiles. Existing exports and existing setups are unaffected.

How I would like to run this thread:

1. I mock each Quick Connect page properly, one provider at a time, starting with Koofr because it is the simplest multi-protocol case.
2. For each provider I post the current page next to one or more proposed layouts, explained field by field, so the choice is visual not verbal.
3. Ehud (and anyone else) replies inline to the options, we converge, and only then do I wire the chosen layout.

Next post in this thread is the first set of Koofr mockups. Ehud, please react to those and tell me which direction feels right before I move on to the harder pages.

[axpnet]

Koofr first, the simplest multi-protocol connector. Its WebDAV and Native API modes share one account credential (the same email plus app password), so switching protocol here is genuinely just "same profile, different protocol", which is exactly the case this redesign is about. Layout only, the saved record under the hood is unchanged.

Here is the current Quick Connect for Koofr, both modes, in both states.

When you ADD a new profile the footer is already a single clean Save, which is what you asked for.

Native API, new profile:

WebDAV, new profile:

But when you EDIT a saved profile and switch its mode, that single Save is replaced by three buttons: an x, a green "Save as new", and an orange "Convert to", plus a "Replaces the original profile" note. There is so little room that the labels truncate to "Save as new ..." and "Convert to Na...".

Native API, editing and switching mode:

WebDAV, editing and switching mode:

This footer is the heart of what you raised:

I don't see a reason for these x, 'Save as new profile' and 'Convert to Native API' buttons personally. I would prefer it if a user would just copy a server from the My Servers page if they wanted to.

the green Save button should act like the Convert to Native API button

So the proposal is to make EDIT behave like ADD: one single Save that converts the profile in place, no x, no "Save as new", no truncated labels. Duplicating a profile is done from the My Servers page, not from this form. The protocol selector sits as the divider, the fields above it are shared across modes, the fields below it (for Koofr, only WebDAV's Endpoint URL and Port) are protocol specific, so for a shared-credential connector like Koofr the form barely changes between modes.

Proposed layout (Native API shown; WebDAV is the same with Endpoint URL and Port appearing below the protocol selector):

Open points for this page:

• The Save button is currently green in Native API and blue in WebDAV for the same account; the redesign should settle on one consistent colour.
• Duplicating a profile moves entirely to My Servers (copy), which removes "Save as new" from this form.
• Overlays Remote Path placement and default wording inside the Wrappers / Overlays block.

Ehud, does this match what you had in mind for the edit and mode-switch flow. Once Koofr is settled I will bring the same treatment to Filen, MEGA, OpenDrive, FileLu and 4shared.

[EhudKirsh]

Thank you for your effort on this topic. Here are the changes that I like from your screenshots so far:

• The icon shares the same row as the profile/connection name at the top and to its left.
• Moving the protocol selector to the column of the required connection settings, below the password and above the endpoint URL.
• The Local Path is now above the Remote Path.
• A single Save button, for simplicity, as seen in your last screenshot.
• I think that a good place to put the Overlays Remote Path outside of the green rectangles and above them. It'll be the same for all 4 overlays, so it makes sense for it to be the one field in the Wrappers / Overlays collapsible section that's outside of the green rectangles.

Here is my feedback on your draft screenshots:

1. I prefer all the optional settings to be on one side, and all the required settings to be on the other. This makes it easy to see which setting is either. Since I like the icon and name at the top-left, I prefer the optional settings to be on the left.
   So please have all the settings in your last screenshot switch columns except for the icon and name.

2. See how in your first screenshot the required settings on the left are in their own rectangle that has a different colour from the background. Let's put the settings on the right also in such a rectangle. And then instead of writing '(optional)' next to settings, you just start a whole rectangle/column with "Optional Settings:", while the other side can write "Required Connection Settings:".
   I like making it really clear, using sections to indicate whether any setting is optional or required. The nice thing is that you only need to write 'Optional' and 'Required' once per Quick Connect protocol, and everything that follows is clear.
   I would also like the Local & Remote paths to be in their own rectangle sub-category.

3. I prefer consistency in structure, so if we have the Endpoint URL of Koofr WebDAV below Username and Password, let's also have the same order with OAuth Client ID, Client Secret and Redirect URI. Basically, a username/email/ID, then password/secret, then URL.
   This is already the case for S3, and it seems that you agreed just now for Koofr WebDAV, so let's keep this order also for OAuth.
   I also really don't like the idea of elements switching places for no apparent reason between creating and editing.
   So if we decide that it makes sense to put the URL below the password in one scenario, and there's no reason to put it above the email and password at other times, then I strongly suggest putting the URL always below the password.
   This will be the order that users will always grow to expect because it makes sense.

4. I suggest moving the connection name a little to the right to leave space to write 'Icon' above the icon.
   The position of PROFILE NAME in the last screenshot of your next comment is excellent.

5. I'm not sure why there's a 💾 icon in the connection name; it seems arbitrary. I suggest deleting it from the connection name, and in fact, it should go to the green Save button, as I currently see it missing from your last screenshot.

6. More consistency feedback: Please replace 'PROFILE NAME' with 'Profile Name'.

7. Not sure why, but I don't see the 📁 symbol in the button to the right of the Local Path in your last screenshot.

8. I personally believe that the explanatory text you wrote is well-meaning but unnecessary. I suggest removing such text.
   There's irony here, which is that much of the point of putting the endpoint URL of Koofr WebDAV below the protocol selectors is to save on needing to write text to explain this, but you've written text to explain this anyway. Basically, you added text to explain that you don’t need to add text to explain. This is an interesting instance where showing off takes away what you just showed off, so you no longer have it to show off. Seeing a URL appear and disappear based on the selection makes it very clear. You can even add an animation of it appearing and disappearing. The text almost makes the experience feel like an introductory tutorial, which some apps make.
   If you insist on keeping the text, please add a setting in '⚙ Settings' > '🎨 Appearance' > '🖥 Interface' to hide it.
   Some of that text even overflows, namely under Crypt (Encryption).

9. I think the Save button looks better in green, but you can always add it as a setting in '⚙ Settings' > '🎨 Appearance' > '🖥 Interface' if you think it's worth having a setting for it.

10. I'm not a fan of the 'Sign in with ' OAuth button. I'm trying to change the icon of OneDrive, and because there's no Save button, it opens a tab in my browser to log in. I'm running into another issue with that, but that's out of scope here, so I plan to discuss it elsewhere. For now, please add a Save button to be able to change the icon and other settings.

More feedback on the Quick Connect pages of v4.1.0-v4.1.1 outside of your screenshots:

11. Please add a hollow star ⭐/heart ❤ that fills up when it's toggled on as I showed in
    [BUG v3.8.2] Can't switch protocols when editing Filen profiles #215 (comment). It should write Favorite above.

12. I noticed that there's a ❌ to the right of the connection name to remove a custom icon.
    This is like storing a pair of gloves, socks, or earplugs in different places, despite needing them to work together in pairs.
    The ❌ should be next to the icon. Perhaps at either of its top corners. Certainly not on the other side of the connection name field.

13. In 'Wrappers / Overlays', as a follow-up to [BUG v3.8.2] Can't switch protocols when editing Filen profiles #215 (comment), much like I prefer to keep the API key accessible in Filen's Quick Connect page, I'd like the Crypt password kept in the Quick Connect pages. I'd like to be able to see which password I'm using. You can have an "⚠ are you sure?" popup when the user tries to make any changes to it, but the user should still be able to have more control than they currently have.

14. Switching between the Native API and WebDAV changes the placeholder of the Remote Path. The idea is that the Koofr Quick Connect page will no longer switch between 2 webpages, but it'll be a single webpage with a checkbox for switching the protocol, as simply just another input field. So elements like the placeholders shouldn't change. Likewise, with the Email and Username changing and Password and App Password, and other text. Only the Endpoint URL makes sense to appear and disappear.

[EhudKirsh]

A follow-up on this: Please write Protocol above the protocol selector radio buttons, so they're consistently labelled like all the other inputs. The only other input that I see in your last screenshot that also needs a label is Icon, which I noted in my bullet point number 4.

[EhudKirsh]

Regarding API Quick Connect pages with 2FA, namely Internxt, MEGA and Filen:

• Please save space by putting the '🔑 | 6-digits | copy-button | timer' to the right of the '2FA Secret' text and above of its input field.
• Please decrease the width of the 6-digit TOTP field to fit only 6 digits, and change its placeholder to 000000 or maybe ▯▯▯▯▯▯.

I was even thinking of combining these 2 points somehow so the 2FA secret will generate TOTPs directly in the TOTP field, but I still think about how to design it so it would look good. These two points, for now, should be very easy to implement by just changing HTML and CSS, not even JS or Rust. It'll be easier to see what to change next after seeing both changes.

[axpnet]

Both layout points shipped for v4.1.2 across all three 2FA Quick Connect pages (Filen, MEGA, Internxt): the code field is now a compact six-glyph input with a 000000 placeholder, and the live TOTP row (key, code, copy, timer) moves up onto the "2FA Secret" label line on Filen and MEGA (Internxt has no saved-secret field, so just the field is compacted). On your third idea, generating the TOTP straight into the field: I like it but it changes what the field means, so I am keeping it for a mock before wiring it.

Details in the v4.1.2 tracker: #384

[EhudKirsh]

More Filen and MEGA Quick Connect pages feedback:
If Filen CLI is present, please use the 6-digit TOTP or 2FA secret to run filen export-api-key. This is similar to how AeroFTP logs in to MEGAcmd by itself and fetches the WebDAV Endpoint URL, so the user can use MEGAcmd through GUI alone, specifically AeroFTP's GUI.

By the way, I noticed that when deleting the MEGAcmd WebDAV Endpoint URL, saving it and then connecting, it connects to http://127.0.0.1:4443/. You can see this both as the placeholder and when clicking '🖊 Edit'.
I suggest that it would fetch the endpoint URL if it's empty by itself using mega-webdav /.

[axpnet]

Good catch. On the MEGAcmd endpoint: this is already handled. On connect AeroFTP runs mega-webdav / itself and adopts the address it prints, so an empty endpoint is auto-filled with no manual step (landed for #215 and #360). The http://127.0.0.1:4443/ you see is MEGAcmd's own default serving address, so connecting there is correct: the placeholder and the Edit view just show that default. If the bridge is ever unreachable (MEGAcmd not running or not logged in) the connect surfaces the error instead of silently using 4443.

On filen export-api-key from the 2FA secret: noted as a nice parity with the MEGAcmd auto-fetch, I am tracking it for a later pass.

[EhudKirsh]

kDrive’s Quick Connect page:

I have great news that I know you’re going to love! I managed to find a link that takes you directly to the ‘API tokens’ page in kDrive’s Developer section, which is what we lacked in #110: https://manager.infomaniak.com/v3/ng/profile/user/token/list.

Here’s how I found it: go to https://manager.infomaniak.com ➜ click on your user icon at the top-right ➜ click on ‘Manage my account’ ➜ right-click on ‘Developer ↗’ ➜ click on ‘Copy clean link’. That link is https://manager.infomaniak.com/v3/ng/profile/user/applications/list. Opening it takes you to the ‘API app’ page, which is a sibling to the ‘API tokens’ page. Going to each changes these URLs by adding the numeric user ID, but I noticed that the only difference between them is the words applications and token, so I switched between them, and it worked! I now also noticed that if you go to these pages, delete the numeric user ID from the URL bar and press Enter, they just refresh the page and the URL.

Also, we covered how to generate an API token for kDrive in #110, but haven’t actually covered how to find the Drive ID. I forgot how I even found it. It’s confusing; it’s a different 7-digits than what appears in the URL bar when entering https://manager.infomaniak.com.
Here’s how I managed to find it: enter https://ksuite.infomaniak.com/all/kdrive, and the Drive ID is the 7-digits that appear in that URL bar. Notice that this number is greater than the user ID in https://manager.infomaniak.com, probably because users can have multiple kDrives.

What this means now is that it significantly simplifies the docs and allows adding this link to the Quick Connect page of kDrive,
like the green '↗ Create Account' and the orange '↗ Generate Password' in Koofr's Quick Connect page.

So the special changes that I propose specifically to kDrive’s Quick Connect page are as follows:

1. As a follow-up on my point 3 in my first comment in this thread: I realised that the Drive ID in the Quick Connect page of kDrive essentially acts as the ID, as its name suggests, while as the 👁 suggests, the API Token acts as the password.
   So to keep the structure consistent, please switch their places, so the Drive ID is above the API Token.

2. Much like my TOTP feedback, the width of the Drive ID input field should be narrow. Unlike TOTPs, it’s not guaranteed to be a certain length, like 6 digits. I have a 7-Drive ID, but I asked AI, and it claims that it’s not hardcoded for a maximum of 10 million users.
   So you might wish to shrink the Drive ID input field to a width of, let’s say, 10 digits, so it’s a little over the entire world population to be on the safe side. You can write 1234567 or something like it as a placeholder to emphasise that a numeric input is expected.
   The exact length of the placeholder can change whenever the number of Infomaniak users changes by another digit, which I don't expect to happen very often, to put it mildly.

3. Adding a green ↗ hyperlink at the top-right of the Drive ID input field for https://ksuite.infomaniak.com/all/kdrive.
   Thanks to my previous point, you’ll have a little bit of extra space on its right to explain that the numeric Drive ID that we’re looking for appears in the URL bar when clicking on the green hyperlink.

4. Adding an orange ‘↗ Create an API token’ or a similarly worded hyperlink to https://manager.infomaniak.com/v3/ng/profile/user/token/list at the top-right of the API Token input field. This replaces the 'Generate a token in Infomaniak Manager → User Profile → Developer → API Tokens' line, so feel free to delete it as it's no longer needed.

Please note that since you watch this repo, you should’ve received an email that I added another comment over the last day in #321. However, I decided to remove it, because after posting it, I discovered https://manager.infomaniak.com/v3/ng/profile/user/token/list,
so I decided that this is a better place to write about it.

Also, this post should be a place to discuss the design of all Quick Connect pages, not only those with multiple protocols.
Please rename it to reflect this. I don't seem to have an Edit button to rename this post, since I didn't create it.

[axpnet]

That direct link is exactly what was missing, thank you. The kDrive Quick Connect help text now links straight to the Infomaniak API tokens page (https://manager.infomaniak.com/v3/ng/profile/user/token/list), closing the #110 gap. Shipping in v4.1.2.

[EhudKirsh]

More Quick Connect feedback:

• Please write the names of cloud drives consistently without ALL CAPS at the top-right of their Quick Connect pages.
  Currently, the following profiles should be revised in this aspect: Dropbox, OneDrive, Jottacloud, box, kDrive, Filen, pCloud Drive,
  Google Drive, and a bunch of others. Of course, MEGA is a special case because it’s normally spelt like that, so it should stay.
  You can see that S3Drive, Koofr and OpenDrive are written correctly as good examples.

• Input fields that only expect numeric inputs should be scripted to reject all other characters which aren’t digits, namely letters.
  The 2 examples that I found for this are the Drive ID for kDrive and the TOTP fields for Internxt, MEGA and Filen APIs. Honestly,
  I think the easiest way to consistently avoid problems like [Tracker] AeroFTP 4.1.2 - Known issues, patches & updates #384 (comment) is to create a TOTP CSS class, so the styling is consistent in any applicable Quick Connect page that supports 2FA.
  Here's a demo I scripted:

<!DOCTYPE html><html>

<b>6-digit TOTP (not saved)</b><br>

<div class='TOTP'>
	<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
	<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
	<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
	<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
	<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
	<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
</div>

<br><b>Drive ID</b><br>
<input id='DriveID' type='text' inputmode='numeric' maxlength='10' placeholder='1234567'>

<style>
	input{margin-top:8px}

	.TOTP{display:flex;gap:8px}

	.totp-box{width:18px;height:24px;text-align:center;border:2px solid#ddd;border-radius:6px}
	.totp-box:focus{border-color:#0055ff;outline:none}

	::placeholder{color:#d6d6d6}
	.totp-box:focus::placeholder{color:transparent}

	#DriveID{width:78px}
</style>

<script>
const inputs=document.querySelectorAll('.totp-box'),L=inputs.length
,handlePaste=e=>{
	e.preventDefault()
	const pastedData=e.clipboardData.getData('text').replace(/\D/g,'').slice(0,L),l=pastedData.length
	for(let i=-1;++i<l;)inputs[i]&&(inputs[i].value=pastedData[i])
	l&&inputs[Math.min(l,L-1)].focus()
}
,handleInput=e=>{
	e.target.value=e.target.value.replace(/\D/g,'') // Only allow 0-9 digit inputs
	e.target.value&&e.target.nextElementSibling&&e.target.nextElementSibling.focus()
}
,handleKeydown=e=>{// The arrows keys can navigate between the 6 TOTP fields.
	switch(e.key){
		case 'Backspace':
			!e.target.value&&e.target.previousElementSibling&&e.target.previousElementSibling.focus()
			break
		case 'ArrowLeft':
		case 'ArrowUp':
			e.preventDefault()
			e.target.previousElementSibling&&e.target.previousElementSibling.focus()
			break
		case 'ArrowRight':
		case 'ArrowDown':
			e.preventDefault()
			e.target.nextElementSibling&&e.target.nextElementSibling.focus()
			break
	}
}

for(let i=-1;++i<L;){
	inputs[i].addEventListener('input',handleInput)
	inputs[i].addEventListener('keydown',handleKeydown)
	inputs[i].addEventListener('paste',handlePaste)
}

// Only allow 0-9 digit inputs
document.getElementById('DriveID').addEventListener('input',e=>e.target.value=e.target.value.replace(/\D/g,''))
</script>

</html>