contact request: bad usability

[rabuzarus]

I think there is a big usability issue with the contact request process (trying to connect with friends).

Let me explain the problem:
There 3 steps until a request will be sent as notification and email.

1.) You are on a users profile page and press on connect.

2.) On the next page you will ask if you know the person. If you press the 'send request' button, a field pops up with the information, that the request was sent (important: in reallity at this step no notification/email was sent to the person you want to talk to)

3.) Only if you press 'apply' on the next page a contact request will be send as notification/email to the other user.

If you leave the the contact request process after step 2 the other user won't get any notification (and he/she wouldn't be able to accept the request). After the failed request process there seems no possibility to send a contact request again. If you try this, you will get a message that you have allready requested this person.

On my personal friendica installation 5 of 8 users told to me that they have sent a connection request to me but I never got one.

There may exist different possibilities as soltion (e.g. info popup after step 3 and not after step 2 or a warning if you haven't finished the request process)
My personal favorite would be to merge step 2 and step 3 in only one step.

[silke]

I agree that the process has too many steps. Is it feasible to merge steps 2 and 3?

[FlxAlbroscheit]

I 100% agree with this idea, the current way it's done is very disturbing and hard to understand for new user's trying to get familiar with Friendia. Right now I'm developing an UI-prototype where the friend-request-process was ought to be done within a single popup/lightbox: No need anymore to switch between both networks to connect. However, I don't know whether it's possible to implement such feature on the software-side, but at least in two case's it could be done easily:

A) Your friend is on the same network/server like you...
B) Your friend is on another network/server, but as you came there using this nice ?zot=xy@xy - identification-parameter, the connect-process can take place in an iframe...

...just to give you an idea :)

[annando]

I'm not sure if the protocoll allows this. I have to check whether a change could create a security problem. Connections to Diaspora and GNU Social could be (easily) done in that way.

[TupambaeNet]

I'm used to the diaspora way of connecting in the last time and if it's possible to connect at least to diaspora and gnusocial directly in the stream (like on D) that would be a great improvement. Actually to conect to D users right know is .. visiting homepage .. copy address .. goto contacts .. .
What we would need is a drop down in any avatar (reshare avatar andcomment avatar) with basic function like connect/drop/block.

[FlxAlbroscheit]

+1 :)

Fabio already created some nice mockup's referring to this issue (https://fc.oscp.info/display/168119876027595292354e75d6d69c6c). However, I see a problem in the fact that the Friendica-interface is not "homogenous", meaning that features such as adding contacts can (or should) only be done whilst being logged in into your "home"-network. To find a solution, we would not only have to change the UI, but also parts of Friendica's infrastructure (which could be another goal for Friendica 5.x ?!). OR we put the whole friendship-process into lightboxes/iframe's, so that you won't need to leave your contact's page to submit your friendship.

[annando]

I had a look into the procedure how contact requests are done. I guess we can do a contact request with a single click without any changes to the protocol itself. Only the contact request had to start from the own server - and not the foreign server, like it is done by now.

[rabuzarus]

I know that that you are very busy but can you give this issue some priority for the next release?

On my server many people did it wrong and could not connect with me because friendica says that they have already sent a connection request.

One time it happens to me too. I wanted to connect with some of the news profiles (I didn't know anymore which one it was - golem or taz). While connecting the browser freezes and I had to close the browser. After this I wasn't be able to connect to the profile anymore because friendica tells me that I already have sent a connection request.

This bug is a real showstopper

[rabuzarus]

Possibly related:
#1012

[strk]

Agreed this is a huge obstacle for newcomers.

[redmatrix]

When Friendica and DFRN were created there were no protocols for "friending". Diaspora was being developed in secret. StatusNet only allowed you to follow somebody, but there was no easy way to put a "Friend Request" button on somebody's profile page in a distributed world to match the Facebook capability. I created a mechanism to do this - which asked for your address so we could link the two accounts across two servers. It's a mess. I abandoned DFRN in 2012 and started on something which learned from all the accumulated mistakes that were made in Friendica and set about to sort them out. Now we basically know who you are already and can link back to your own "follow" interface. So one click and you're done.

So in Friendica you can do a "follow" just like Status.Net, but if you want to put a "connect with me" button on your profile page it gets more complicated. The options are basically re-invent zot magic-auth or get rid of the "connect with me" button on the profile page. Otherwise the profile page has to ask "well who the heck are you and how do I contact your server?". There's a primitive form of magic-auth in Friendica so you can possibly do this with one click, but it involves a whole lot of probing and cross communication before you can load the page. If you're going to stick with DFRN I would recommend you just get rid of the connect button on the profile page and do everything from your own site. Then you can make it one click.

[strk]

Staying in your node is the proposal made by Fabio: https://fc.oscp.info/display/168119876027595292354e75d6d69c6c

I think the question "who the heck are you" is a very common one and standard protocols exist that are meant to respond to it. I'd like to see OpenID being used more, for example, and it wouldn't be bad to add more information in the so called "global registries" for federated identities (like the global directory of Friendica users). For example, what if the global registry would inject cookies to the visiting browsers to allow them to be recognized as serving one or more identities to be picked from to redirect the user to her own node ? You as a federation user would only need to setup those cookies once for used browser and be done. Or another idea would be to deal with this completely at the browser level, adding support for some new dfrc:// or zot:// protocol uri scheme (brainstorming now). But in general, all development are only possible when a protocol is well documented and stable over time, and as simple as possible to understand (I'd add).

[miqrogroove]

Even if the process starts on the wrong server, it should be possible to AJAX this and walk the user through the process in a more painless fashion.

I agree this is among the worst problems with Friendica today.

[annando]

This very complicated process lies deep in the DNA of the old transport layer. In fact we only use this old method when we are visiting foreign websites (which can be replaced by the magic auth) and when removing a remote contact.

Means: I would like to postpone this, until we deprecated our own protocol.

[miqrogroove]

That is not accurate, and I don't know the extent to which it is caused by other bugs, but in my experience the multi-step friend request is always used, even with local requests.

[annando]

You misunderstood :-) What I was trying to say: This process generates a key pair in the contact table that is only used for the two described purposes. For example: When we transmit messages, we are using the Diaspora transport layer that doesn't need these keys.

[annando]

This should be solved now. Since the current stable version we are using the ActivityPub method for connecting.