User Experience: control for the user or behind the scenes magic?

User Experience: control for the user or behind the scenes magic?

One of Deveo's core values is simplicity. Even though we deliver solutions to quite complex problems and tackle the needs of larger organizations, we believe that a simple, easy to understand user interface (UI) and user experience (UX) are essential. In this blog post, I'm going to share an example of one simple user experience decision we made lately, and the decision-making process behind it.

The problem:

With Deveo you can manage and host Git, Subversion, and Mercurial code repositories. The repositories can be accessed either through HTTP or SSH protocols. It's typically a matter of preference, which one you would like to use. There are cases, however, where SSH traffic has been blocked entirely, which forces you to use HTTP. If the latter is not the case, the choice is with the end user.

The default choice to show in the Deveo user interface has been HTTP. This is due to the fact that HTTP-based repository access requires no extra configuration from the user point of view. During a version control operation that hits the server and requires authentication, the username and password are used to authenticate. SSH, on the other hand, requires the user to configure an SSH key to Deveo.

We received some feedback and requests, whether SSH protocol could be switched as the default, and whether this could be configurable for the user. We heard the feedback and decided to act upon it. However, where and how to configure this became the next question.

Solutions we thought

Deveo is multi-tenant by nature. This means that in one Deveo:

  • one server can have multiple companies,
  • one company can have multiple users,
  • one company can have multiple projects, and
  • one project can have multiple repositories.

Thus, the different places to configure default protocol setting for repositories would be:

  • the instance level
  • company level
  • project level
  • repository level
  • user level

The instance level is too broad, as there can be multiple companies that might work differently. We would need to choose a default for the whole Deveo cloud instance for example. The company level gets closer, but the same problem is still present. There can be multiple projects with different needs. In addition, a company level setting could only be changed by a few people in a given company. Project and repository levels are pretty good, but there could still be individual preferences over the protocol choice.

The user level is the place where this kind of decision should be made. However, even with user level, there's a problem that the user might not know that such a setting exists. Thus we needed to think of an alternative way.

The solution and simplicity

So how about not offering a setting at all, but simply make it "just work" most of the times? This would sound like a good idea, right? In Deveo 3.6 we had implemented a user experience enhancement that saved the collapsed state of the side menu in browsers' localStorage.

This approach fits pretty well for the default clone URL protocol selection as well as the setting is individual for every user and the user does not need to know that the setting even exists, it simply works. We applied the pattern here, and implemented the choice in a way, that when a user selects a different protocol to be used, it will be saved to the localStorage. Whenever using the same browser, the user will get the protocol he wishes to use in most of the cases.


The default repository clone URL protocol setting will be released as part of the upcoming Deveo 3.12 release. The purpose of this blog post is to demonstrate how a choice of implementation can have an effect on the user experience and what kind of thought process we went through while iterating over the solutions. Do you think the choice we made was correct? Or do you have a good story about a user experience choice you made that gave you a similar revelation? Share a link or comment below.

Seamless software development.

Code management and collaboration platform with Git, Subversion, and Mercurial.

Sign up for free
comments powered by Disqus