Jump to content

Rename Protocol Encryption options to something more obvious


Recommended Posts

A lot of users including myself have been confused about what Protocol Encryption (Forced/Enabled/Disabled) means and have to post or search the forums to find out what each setting means. (You only need to search the forums to see the many misunderstandings)

Simply renaming the options should make it more obvious about what each setting does.


Protocol Encryption (Forced / Initiate / Comply)

When I studied Human Computer Interaction & Design, one principle resonated with me. The better the interface (the more obvious the controls effects are) the less need there is for a manual and support. And conversely the need for referring to a manual or requesting support reflects on the efficiency of the design.

Link to comment
Share on other sites

Initiate (early cleric that just joined the monastic order)?!

Comply (Comp-uter-ly? Compliance with law? Comp-atibi-ly mode?)

I'm not fond of your suggestions. :P

The real kicker is people don't recognize allowing incoming "legacy" connections means also ALLOWING connections "not using encryption". ("legacy" = "not using encryption")

THAT's a far bigger misunderstanding than outgoing encryption.

Link to comment
Share on other sites

What's "comply" supposed to mean? Who in their right mind would ever think of "comply" as being equivalent to "disabled"? How is "initiate" any better than "enabled"?

On the other hand, the current labels rather clearly indicate that these dropdown options are only for Outgoing connections (meaning they have no bearing on incoming connections), and that you either force (require) outgoing connections to be encrypted, enable (allow) outgoing connections to be encrypted, or disable (prevent) outgoing connections from being encrypted.

The only potentially "ambiguous" option is Enabled (since it would overlap the positively-connoted Forced option), but given the context, I think it's clear that the options are in a "this, that, or both" format, and since Forced and Disabled are obviously mutually exclusive, that'd only leave Enabled to be both. Enabled doesn't have a strict connotation to begin with -- unless you're expecting the reader to be a person who thinks "getting a driver's license ENABLES (which is different from FORCES*) you to legally drive on the road" still means "getting a driver's license means you MUST drive on the road".

* This parenthetical statement is in the analogy because "Forced" is similarly differentiated from "Enabled" in µTorrent.

(You only need to search the forums to see the many misunderstandings)

Have examples of the many misunderstandings? I can't recall when the last time was that someone asked what these options meant, as opposed to just asking how one could set µTorrent up to circumvent ISP throttling (which is a much broader question).

Note: I realize that this reply is a sharp response to your polite suggestion, but I'm one to take usability and good design very seriously. Although I've never had any formal HCI or design training, I'm still subject to reading/understanding the option as any other user, and your suggested strings appear to me to be worse than the current strings. That is, they raise more questions than they answer (if they answer any at all).

Link to comment
Share on other sites

Some examples of people not understanding/trying to explain what the various settings do

















Most users don't post on forums or ask about every option they don't understand, imagine the number of users who don't understand these options.



As a user, you want to either:

* Have only encrypted connections (your ISP shapes heavily)

* Have encrypted connections wherever possible (your ISP shapes a bit)

* Have minimum number of encrypted connections (if your ISP doesn't shape, or you want to save CPU)

So thats what users want, now that must be translated into options users can understand.

Remember the model you have in your head is the designer's model, your intimate knowledge of bittorrent procotol etc makes the meaning of the options obvious to you.

Users have a "user's model" in their heads of how bittorrent works, which is a simplified and usually inaccurate idea of how the system works.

They just want a result. They need to figure out what input to give to get the desired output.

The average user sees that if they turn up the heater in their car to max temperature the air in their car heats up faster. So they often try this with the thermostat in their house, or with their oven in their kitchen, turning their oven up to 300C and then down to 180C later, not understanding that the control in their car adjusts the mixture of hot/cold air; and the control of their thermostat in their house/oven just sets the 'off' threshold, and that the heating power is constant.

If the control in the car were labelled 'hot/cold air mixture' instead of being labelled 'Temperature' probably a lot more people would understand how to use it.

Ultima: HCI is a very interesting science, you actually learn how your own cognitive processes work, which is really cool. Check out the book 'Design of every day things'. Amazing read for someone who designs/builds stuff.

I think people misunderstand what Protocol Encryption outgoing/incoming means. They might think that incoming/outgoing relates to uploading/downloading.

Why should there be seperate options for incoming and outgoing?

As far as I understand it whether the connection was initiated as incoming/outgoing really makes no difference to the functionality of Bittorrent, its got to do with who can receive incoming connections/who cant and who seeks new connections.

Here is my logic, If you're going to force your outgoing connections to be encrypted then surely you would want to force your incoming connections to be encrypted too? (Making the tick box for 'Allow incoming legacy connections' unnecessary)

I don't understand why you're making users make decisions about having encryption/not separately on incoming and outgoing connections.

People don't understand the difference between enabled and forced.

Some people think Disabled means there will be no encrypted connections at all.

My assertion is that the mapping between the options and the results is blurred in a lot of user's minds.

The options should translate simply to the above 3 possible goals. Unless the protocol doesn't make such a simple set of options possible, I think the next best thing would be best.


I should have communicated more clearly in my previous post, my 3 suggested labels for the options in my previous post were for

Protocol Encryption (blah, blah, blah)

(irrespective of outgoing/incoming)


Protocol Encryption Outgoing (blah, blah, blah)

Forced - Maps to the first option well (only encrypted connections)

Initiate - Means try establish encrypted links, so that if its supported by the peer, it will be encrypted. (not so good)

Comply - (okay I guess this is crap)

How about:

Encrypt Connections:

Force (For heavily shaped internet connections)

Encrypt connections whenever possible (For shaped internet connections)

Encrypt only if requested by peer (For unshaped internet connections)

Link to comment
Share on other sites

As I expected, you didn't actually dig up any recent posts asking about what the options meant. You linked to posts mainly asking about or answering what Protocol Encryption is for, and posts from when it as first introduced (early 2006). Naturally, if it's completely new technology, people are going to ask what it's for -- that doesn't reflect on the understandability of the option values themselves.

Of course it would be great if a UI can make each and every option's usage obvious, but with functionality as targeted/narrow as Protocol Encryption is, there's no way you can explain it without writing a full-on explanation in the UI. In which case you're not making the thing more "usable" -- you're just just stuffing the manual into the UI, which would be no better than the current arrangement.

Why does µTorrent distinguish between incoming and outgoing? Because the original design decision was made that µTorrent should always accept encrypted connections, no matter what. If someone else initiating the connection requires encryption to be able to use BitTorrent, why should the choice to accept it as encrypted be placed on the user? Your problem seems to be with the lack of symmetry in controls for incoming and outgoing connections.

Link to comment
Share on other sites

  • 2 years later...

i don't understand it all that much, but i'm guessing a lot of people don't. I was wondering if someone could explain in regular English how to set utorrent up to stop bandwidth throttling from my isp, yet keep a good upload and download speed? (possibly step by step) please and thank you.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...