We recently blogged about the 6 ownCloud user interaction design principles from a conversation with ownCloud designer Jan. In this blog, we talked to ownCloud project lead Frank to cover the priorities underlying technical development: keeping data safe, being easy to use and being fast. Why these three and what happens when they conflict?
Primary Goal
Towards an end user the main goal of ownCloud is to, without any work on their part, always do what the user expects. This might be a captain-obvious statement and seem like a massive over-simplification, but it is an important goal to keep in mind. Frank recently blogged about the new ownCloud slogan “A safe home for all your data” and this forms the base under the three rules for ownCloud development decisions.
Security is important for ownCloud.
Rule 1: keep data SAFE
Doing what the user expects, of course, includes not losing data. ownCloud should NEVER lose user data. This again might seem obvious but due to both technical and social circumstances there are countless situations where users could end up losing data, many of which are not even due to faults in ownCloud itself. We have to think of each of those and do something about it before that happens and think beyond the ownCloud code itself!
Compare this to being a car company. Your first priority should be–: nobody dies! So you make sure that the care you give is bigger and strongera bigger, stronger care. But what if people don’t check tire pressure? You have to warn them, beep and blink. If the user forgets the seat belt, you have to remind them. Is that annoying? Yes. Will they dislike it? Yes. Do you offer a switch to turn it off? No, you must force the user to be safe.
We follow the same rule: you want to get rid of all ways users could lose data, even if it is due to a problem in the underlying technology rather than ownCloud itself and even if it is the users’ fault. We could say “you didn’t read the documentation;, your fault” or “you didn’t do a backup;, your fault,” but this is not the right way of dealing with people and their data.
Security is a part of this, of course, and security is indeed one of these things people often find annoying. But, to keep their data safe and secure, you have to make tough choices sometimes.
ownCloud 8.2 introduced a easier, cleaner UI
Rule 2: be easy to use
The second key goal for ownCloud is to be easy to use. This not only means having an easy, simple user interface, but also to try and avoid making the user do manual work. And this is extremely hard. Take updating – you want the upgrade to happen by simply overwriting the files with a new version. The rest should be handled by ownCoud. This is freakishly hard to do in a way that is 100% reliable (see rule number one!) and a constant focus in our development!
Rule 3: be as fast as possible
The third rule is simple: ownCloud should be fast. Nobody likes to wait!
Together
The challenge is how these three goals relate to one another. Do you compromise data safety for speed? Do you reduce security to make ownCloud easier to use? Is it acceptable to run an upgrade automatically even if that risks data loss in 0.01% of the upgrades?
We put the rules in this order for a reason– we never compromise rule 1 for 2 or 3, nor 2 for 3. Don’t ever lose user data and be easy to use and fast as long as you don’t compromise safety!
We use Blackfire to profile our code.
This is a constant topic of discussion and something to always stay on top off. There are always many ways to think of a problem. Take warnings. ownCloud tells you when your user folder is world-readable, as that is a security thread. This annoys some users and they have asked for a button to ignore this warning. We have not added this, even though people call our support and ask how to remove the warning! Our answer is– do what the documentation tells you and secure the installation. We don’t offer a way to hide a problem! Users even submit bugs about this– ownCloud claims it can’t connect to the internet and certain functions are missing. Well, it says that for a reason – it is not a bug! Though, in this case, we allowed users to disable the warning in the config file as it was functionality-related, not a security or data safety problem.
Sometimes, you can use clever design to help the user not lose data. Offering an undo for many actions and use of the trashcan are two ways of doing that. An example involving speed vs safety is when we discussed a config option where ownCloud will never do the database migration test again because it takes so much time during the upgrade. That is essentially a feature to permanently remove a safety feature. Frank was clearly not a big fan of it, believing we always protect the user, even if they don’t like it!
We thus continue to put effort in all these areas. While ownCloud 9 will make significant improvements in speed, it also enables clients to store and retrieve checksums on files they sync with the server. Is it likely that a file gets damaged while it is being sent over a secure connection to the server? Not at all, but even though it is extremely, extremely rare, an extra layer of protection won’t hurt and future releases will expand on this new layer of data safety.
Together, these three priorities, when developing ownCloud, guarantee that it remains a stable, secure home for all your data, while being easy to use and fast!
What do you think about our priorities in this regard? Your input is welcome and you can always get involved to make it happen!
