Style-Standards & CSS / Style Guidelines

[frankaellen]

For the future we want to set up a documentation especially for frontend, design and css. Following a first brainstorming with a raw structure:

• principles, standards
• simplicity, minimalism
• low-barrier
  • no fancy extras, plugins
• licences (cc, mit, …)
• Usability Testing
  • http://jancborchardt.net/usability-in-free-software
  • http://www.nngroup.com/articles/
  • http://littlebigdetails.com/
  • http://uxmyths.com/
  • http://uxmag.com/articles/quantifying-usability
  • http://ignorethecode.net/blog/
• developing new design patterns
  • collect existing examples, point out advantages / disadvantages, list improvements, mockups, wireframes, develop
  • example: https://wiki.gnome.org/Design/Apps/Music
• coding guidelines
  • browser support
  • Categorizing CSS rules
    • for example: http://smacss.com/book/categorizing
    • base, layout, modules, state, ...
  • Writing Tacital HTML & CSS
    • http://www.youtube.com/watch?v=hou2wJCh3XE&feature=plcp
  • Google's CSS coding guidelines
    • http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
• style & design guide
  • existing classes, ids
  • icons
  • fonts
  • colors
• specifics app development
• specifics core development

What are your ideas? Just feel free to add, edit, refine, etc.

cc @jancborchardt

[frankaellen]

So far a first draft for the first section of a design documentation.

---

Documentation: Design, User Interface, CSS & HTML, Coding Guidelines

In order to enable you a smooth production flow we set up some guidelines for principal design, usability standards, coding guidelines and offer you a wide range of already existing design patterns you can use in your app (or also in core development).

1. Principles and general standards

Rock solid CSS & HTML – Keep it simple

Everybody should be able to participate in the Owncloud development, so the code should be as simple as possible. This affects various areas:

• We love minimalism. Keep your code plain. Avoid dependencies, unclear class- and id-names, don't be stingy with explaining and commenting your code and pay attention to a clear structure.
• Abstain form fancy, new, unknown technologies. They might be very helpful in your everyday work life, but imagine what it costs others' time and effort to adopt and learn them. In a long process of countless discussions we decided against features like sass, haml and so on, because they are almost exclusively a new barrier to enter in developing for Owncloud.

Respect copyright and other licenses

Only use code, icons, fonts and images your are expressly allowed to. Never rely on any code, icons, fonts or images you found somewhere, somewhen on any dubious site in the world wide web. For further information check out http://opensource.org/licenses.

User is king! – Usability testing

The aim of Owncloud is to guarantee an over all satisfactory experience for the user. Therefore design and user interface have a significant value for core- but also for app-development. We hope, you share the same conception and appreciate qualitative user experience. And, as we all know, usability testing is the best way to approve the easy handling of a web app / website.
Following is a collection of blogs, manuals and guidelines for lean usability testing you can make use of:

• http://jancborchardt.net/usability-in-free-software
• http://www.nngroup.com/articles/
• http://littlebigdetails.com/
• http://uxmyths.com/
• http://uxmag.com/articles/quantifying-usability
• http://ignorethecode.net/blog/

Developing new design patterns for apps and core

When developing a new app, or advancing existing ones a standardized process from the idea to the finished product helps getting qualitative feedback, enables detecting gaps and intensive collaboration. A great example for a open, standardized process for new design patterns is Gnome (https://wiki.gnome.org/Design/Apps/Music) with their wiki.
In general you can follow these few steps for the development of your idea:

• collect existing examples
• point out their advantages / disadvantages
• list improvements
• create mockups, wireframes (for example with http://balsamiq.com/ or http://www.axure.com/)
• implement

These steps (and of course sharing them with the community on github) will support a low-barrier collaboration in the community.

---

Would be very happy about feedback and improvements (especially linguistic ones)…

[jancborchardt]

Awesome on starting this @frankaellen! :) As I said, the structure is really great! Let’s flesh it out.
(Will continuously comment with some pieces I take from other parts we already wrote or stuff which we need to have permanent.)

As for coding guidelines, essentially we follow Google’s HTML & CSS guidelines: http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml with 3 exceptions / additions:

• indentation by tabs, not spaces
• our unit of choice is px. (px does not mean device pixels, everything looks fine on retina displays for example)
• declaration order should not be alphabetic, but grouped by what makes sense. Best: position-/size-related, then font-related, then effects (we need to elaborate on that more)

Other specific interface guidelines we should move towards:

• 44*44 px is the minimum size of an interactive UI element (see the iOS Human Interface Guidelines)
• 16 px is the content text size we should aim for (see Information Architects on that)

@frankaellen @owncloud/designers what do you think?

[raghunayyar]

A big 👍

[jancborchardt]

There’s some pages on the website which have frontend-stuff scattered around:

• http://owncloud.org/developer/design/
• http://doc.owncloud.org/server/5.0/developer_manual/app/general/codingguidelines.html?highlight=coding%20guidelines#userinterface
• http://doc.owncloud.org/server/5.0/developer_manual/codingguidelines.html#css
• http://doc.owncloud.org/server/5.0/developer_manual/app/general/codingguidelines.html?highlight=coding%20guidelines#css

Those we should also centralize. I suppose owncloud.org/developer/design is the best location for all of this.

[carlaschroder]

Closed for age and inactivity.