Style Guide
This is our Style Guide to reflect our Corporate Design within our App.
Mindset: Simple and intuitive, data is more important than looks.
Our main App Icon is the red Status Icon indicating threat status DANGER. You can either take it directly from our Apps drawable-xxxhdpi folder by clicking here, or by manually extracting it from our Banner SVG or Status Icons SVG file.
No final decision yet. We prefer open source fonts on GitHub. Some inspiration:
- Calligraphy
- Proxima Nova (not free, used by Spotify)
- Museo Slab 500 (not free)
Want to identify your favorite font? Use WhatTheFont!
No final decision on in-app icons yet. Some inspiration:
- No rounded corners
- Round Icons without outline (except Status Icons)
- Square Buttons if text is used
- Round Buttons if Icons or signs are used
| COLOR | #HEX | DESCRIPTION |
|---|---|---|
 |
#111111 | Background color: Screen and Navigation |
 |
#333333 | Outline of boxes, background of box header, background of Navigation Drawer, form fields (text input, select box) |
 |
#ffec5a | Akzent Color, text of box headlines, buttons |
 |
#929292 | Describing text of values, "unimportant" text (for better overview) |
 |
#f9f9f9 | "Important" values (good readability) |
 |
#ab2424 | Map Marker (single tower), text color for alerts of all kind (or as box background color) |
 |
#35b838 | Map Marker (more towers) |
 |
#2668a0 | Neutral color, use for small objects (own position in the map) |
- Careful use of space, don't leave great spaces
As much as we enjoy your contributions, please keep a high code-quality!
- Follow the Android Code Style Guidelines
- Read How to Write a Git Commit Message
- Make use of the Android Best Practices
- Also respect the Google Java Style, but:
- No column limit to 100 char. (As we all know, our screens are 1 kilometer wide and about 2 centimeters high, so why should we read code 2 cm wide and have to scroll downwards paging through 1 kilometer?)
- No line wrapping. Nobody likes line-wrapping, unless there's a bunch of consecutive objects wit the same name/structure that can be nicely aligned.
- Skip point
4.6.3 - Horizontal alignment. E:V:A loves horizontal alignment, and as long as we use spaces and not tabs, its perfectly great for readability.- Another good thing to know:
Class and member modifiers, when present, appear in the order recommended by the Java Language Specification:
public protected private abstract static final transient volatile synchronized native strictfpThoughts about some parts of the (javadoc-) comments:
-
Description:- Don't prefix the description with
Description:in order to be more javadoc-like
- Don't prefix the description with
-
Issues:andTodos:- Don't track this in comments
- Better track them here at github (or another bugtracker)
-
Changelog:- Don't track this in comments
- We have
git log -- <file>andgit blame <file>for that
- In general the javadoc comments should be more javadoc like:
- Use HTML tags like
<p>and<a> - Use things like:
@see@author{@link <method|class|field>}
- Use HTML tags like
About discussions:
- Don't keep discussion in source code comments
- Use line comments at github for that
About source code comments vs wiki:
- Use source code comments for (technical) information/documentation about a particular class/method/field
- Use the wiki for overviews, manuals and so on
- Flat Design (no shadows, no bevel, no shining edges)
- Rectangular prisms (if possible), 100% width for boxes and tables
- Thin lines color
#333333between text blocks and in the Navigation Drawer
Easy, intuitive and self-explaining. Preferably giving a unique look and feel to our app.
- 1 Color Icons, flat and minimalistic