You want to contribute to the look of ownCloud? Great! Everyone likes an interface which feels alive and empowers the user. Here is how you can get started with contributing to the ownCloud design.
- We have a Design label on GitHub – check out these issues if you want to help and fix interface problems. This label is also in the other repositories for clients and apps.
- For easier issues and to get started, check out the Design issues also marked »Junior Job«
- High priority design issues are additionally marked with the »p2-high« label – these we need to prioritize, and fixing any of those will make you everyone’s hero!
There is an @owncloud/design team on GitHub. This enables people to just mention @owncloud/designers in issues and pull requests to notify all designers. Otherwise you have to mention each one individually.
The people currently in this group are:
Please let us know if you want to contribute to the design and would like to be in this group. You will be notified every time someone mentions this team in an issue, which would be every design issue or pull request.
You should also join the #design-ux channel on talk.owncloud.com. We use this to communicate on smaller issues, talk about what to work on next, and just general chatter. It’s good to get to know the other people and for organization in general.
- Software should work. Only put features into master when they are complete. It’s better to not have a feature instead of having one that works poorly.
- Software should get out of the way. Do things automatically instead of offering configuration options.
- Software should be easy to use. Show only the most important elements. Secondary elements only on hover or via »Advanced« function.
- People’s data is sacred. Provide undo instead of asking for confirmation – which might be dismissed.
- The state of the application should be clear. If something loads, provide feedback.
- Do not adapt broken concepts (for example design of desktop apps) just for the sake of »consistency«. We provide a better interface.
- Regularly reset your installation to see what the first-run experience is like. And improve it.
- Ideally do usability testing to know how people use the software.
- When people ask for features, find out what the root of the problem is. Then fix that instead of just adding a feature.
- Test in different browsers. We need to fully support the common browsers like Firefox and Chrome as well as Internet Explorer down to version 8.
- Test on different devices. The web interface should work on a smartphone or tablet as well as it does on desktop.
- For further UX principles, read Alex Faaborg from Mozilla.
More concrete HTML+CSS guidelines
- We basically follow Google’s HTML+CSS style guide, with small exceptions:
- Use tabs for indentation, not spaces
- Sorting of declarations should be sensically grouped instead of alphabetized. First positioning and sizes, then typography, then colors, then additional rules.
- HTML and CSS building blocks are in the documentation.
- Clickable elements should be a minimum of 44*44px to be easily tappable on mobile devices and well visible on desktop. See the Apple Human Interface Guidelines for reference.
- We don’t use SASS or another preprocessor because of the barrier to entry.
- We don’t use Bootstrap because there’s lots of parts we don’t need and we would need to customize a lot anyway. We do use pieces of Bootstrap though, like Tipsy for tooltips.