Overlays over the normal GUI aren’t so easy to make afaik. I thought of creating some activities with descriptions about the different actions of the app. And maybe with buttons to add/configure folders and devices. Eg one screen “how do folders work + add folder button”, same for devices.
Ja passiert
I’d say all of them, just make sure they aren’t duplicates. I’ve already readded the share button to Android in the mean time.
Edit: You could check other apps like BtSync, Dropbox etc. how they do the introduction stuff. I actually have no idea.
Do we know how much of a difficulty users find communicating device IDs? Have we got an idea of the methods they employ themselves to make it easier? Having read over the challenges and complexities here I wonder if it’s worth getting some information on how how big of a hurdle new users find it.
Anecdotally, I’d say from the forums and IRC, that firewalls not letting through local discovery broadcasts and UI progress not being clear about “what is happening”, for slower devices, are two of the bigger challenges new users come across.
@Nutomic: I created PRs for all of them, but the introductory animation. I still have to draw up the concepts for those.
I’ve had another really simple idea tough:
We can just include a tutorial video on the website which goes through setting up a vanilla installation to share a folder with another device.
BtSync uses different secrets for R and RW, which are simply handed to everyone who is supposed to access it. Their concept misses devices entirely.
Do we know how much of a difficulty users find communicating device IDs?
Have we got an idea of the methods they employ themselves to make it
easier? Having read over the challenges and complexities here I wonder
if it’s worth getting some information on how how big of a hurdle new
users find it.
I’d love to see some data, but for that we’d have to do actual user testing, which is expensive and time consuming. I’ve helped many people setup Syncthing (as in I was physically in front of their computer), and many struggle with the concept and the UI, at least in the beginning.
Anecdotally, I’d say from the forums and IRC, that firewalls not letting through local discovery broadcasts and UI progress not being clear about “what is happening”, for slower devices, are two of the bigger challenges new users come across.
Those are unfortunately pretty biased experiences, because no computer illiterate granny has ever joined an IRC channel in the first place. With the forums it’s a bit different, but not much:
Someone who downloads Syncthing just to check it out and has difficulties early on, which make using it impossible/very tedious, will generally disregard it, because it’s “too complicated”. Those users don’t want to go trough more hassle (registering anywhere), they just want a solution. Also the forum isn’t featured very prominently in the UI and on our website in the first place. So it’s very easy to miss those resources for inexperienced/lazy users.
This is a nice point I’d like to get to though, as it essentially removes the step.
The implementation as is could still have devices underneath, just hidden away from the UI.
One of the day one design decisions was to not use a reusable token for access. That is, it should not be the case that I tell you some secret and you get access, and some third party intercepts the same secret and gets access as well. I’m not at all opposed to some sort of short, simple access token á la the BTsync ones, however,
they should be single use
ideally, they should not require trust in the operator of the discovery servers
I’m not 100% sure how to solve the latter without having an explicit “accept” stage on the source. But having an evil discovery server operator (or a bribed or compromised one, in case we go for some sort of super centralized trusted service) be able to get access to any share just by being part of the exchange of the secret is not acceptable to me. Having a short access code plus PIN is one way - the two could be baked together and only part of it is published in the discovery system.
Baking them together like that avoids the problem of accidentally entering the wrong code - i.e. you get the code abcdefghi where abcd is the temporary short device id, efgh is the shared secret (PIN) and i is a check digit. You need to enter it all correctly for it to be accepted by your Syncthing instance, so you can’t fumble the PIN. We only tell the discovery servers about the abcd part. The actual source device verifies the PIN and invalidates the whole thing on seeing three failures or so. And the whole thing is single use.
Just as as side note: Even the Bittorrent people thought that a reusable token for access wasn’t the best idea, that’s why they changed to a cert based system (like Syncthing) with version 2 a year ago.
I think there’s an underlying assumption that whatever system is used has to result in short tokens - there was discussion about telling someone a token over the phone.
I’d be interested in challenging this - we get a lot of flexibility if the tokens can be long (we can squeeze a device ID + other stuff, meaning the discovery servers don’t need to cooperate).
Would that be worth holding a poll over?
EDIT: I also don’t know if a single other file-sharing utility which doesn’t rely on sending links.
It’s tricky to phrase: you don’t want to people to just go “oh yes, that sounds like a good idea tick” regardless of whether they have ever or would ever use the mechanism described.
Maybe something like “have you ever wanted to share a folder with someone where copy/pasting some text (over sms, email, IM, etc) was not possible?”
It’s also self selecting in the wrong direction, as the people who found it too cumbersome to bother with aren’t here to answer.
Personally I don’t think I’ve ever (yes, ever) typed in a device ID anywhere. Not once. Which just shows that I don’t represent the general population here.
