Should be Roboto, should not it? https://fonts.google.com/specimen/Roboto?selection.family=Roboto

@westnordost Do you remember, which one you did use in the feature graphic at the top of the Readme?
When I open feature_graphic.xcf in GIMP and click the font, it destroys the font and displays "Standard Symbols PS" as a font name? However, I could not find this font online or so…
And as I found out, this is likely the fallback font, GIMP choose, but it is certainly not the correct one…

already in Wiki, but here GitHub automatically adds a small little nice badge behind it, so this looks way nicer 😄 :

• #f3cf62 – yellow (quest icon??)
• #ff6528 – orange highlight (floating button)
• #b5cba0 – green (landuse map)
• #4b6ce5 – blue (river)

• ---

• #529add – blue light background (quest icon)
• #ffdd55 – yellow bright (quest icon)
• #e9a76f – orange (quest icon)
• #9bbe55 – green (quest icon)
• #c84747 – red highlight (traffic sign in quest icons)
• #e45f5f – red highlight 2 (background in notes quest icon)
• #555555 – dark grey (dark stripes/elements in quest icons)

specific meaning (use nowhere else?):

• #3f45b5 – header/frame/footer blue

light colors:

• #fcfcfc – white
• #ddd4bb – yellow light alt (map)
• #bac5d9 – grey (bluish, buildings)
• #959595 – grey (in quest icon)
• #c8c4b7 – grey (quest icon)
• #7f7f7f – grey (street in bottom panel)

Yes or no?

Let's list the content we want to include (mostly taken from original issue streetcomplete/StreetComplete#1130):

• header image of StreetComplete
• some example quests
• Screenshots of real app/animations
• points why StreetComplete is fun/amazing/helps the world
• why StreetComplete is easy to use?
• download buttons somewhere (maybe even fixed?) to FDroid & Google Play(!)
• links to more resources: contributing information
  • GitHub link
  • contributing information -> link to Contributing.md of SC
  • quest list (should this be a small note, or rather something more big at the top linked like "See all our available quests"?)

Things I am not sure about

• Do we want these "Quotes" from users? Marketing-like I'd like it. Don't know though whether we have so much.
• Somehow embed ratings from Google Play? Or at least not embed, but somehow "copy paste" 😉

I'll start to collect some design values (actually already started in the main issue):

• Playfull: StreetComplete is gamified, we want to reflect that, but make a serious website anyway. Playfullness can be hidden in details, etc.
• Interactive: The website is technically static, but should not feel like that. We may embed maps, add quest markers. etc.
• Non-technical: Our target audience are users, who have no idea of StreetComplete, OSM, and so on.
  We will not try to convince them of OSM. We may not even mention OSM, but I guess we should do this, at least somewhere near the bottom.
• Non-standard: The website should not have these usual straight lines, cuts based on height or so. It is a project website, but – combined with stuff above – it should be kept in mind, and not look as any other website.

Technical

• Best goes first: Of course, the best arguments/interactive stuff should be presented first. At the bottom, we can present
• Prototype early: I know it's hard to resist, but let's focus on details later. If e.g. our map markers look bad, we rather want to have them anyway, first.
• Try out: We may revise the design at any time.
• Use new stuff: Websites will anyway get older over time, so we rather use the new stuff.
• Less JS: We may not need it, or CSS is better.

So?

Any other important points? All agreeable?

I really wanna use CSS Grids. It's such a new nice technology and hopefully makes much stuff easier.

https://hacks.mozilla.org/2018/07/9-biggest-mistakes-with-css-grid/
https://cssgrid.io/
https://potch.github.io/grid-talk

https://caniuse.com/#feat=css-grid

streetcomplete/StreetComplete#1130 (comment):

• a one-page is fine, IMHO (there is really not the need for more pages)
• I'd prefer a 100% static version, or (if really need – and I doubt so) maybe Jekyll or another static site processor, but in the end it should be hostable on GitHub Pages, if needed. There is just no need for dynamic stuff and static sites are always the fastest to load
• we hopefully need not so much JS, maybe only for scrolling effects (i.e. click on -> visually scroll to part of the page)

I'll add one more aim: As I want to use CSS Grids (#1), which is a fairly new feature, we may need some fallback.

So what stack do we choose?

• modernizr to support old browsers
• jekyll, because ehm… can it include (similar stuff as) modernizr?
• nothing, plain sites

Questions

• Do we want material design?
• Do we need a lib for that? Do we even may use so mcuh elements of it?
• Choose a small lib that suits our task? (not too much) I guess, we hardly need many icons, fonts or so, or do we?

Choose

• Materialize: https://materializecss.com/
• material-components-web: https://github.com/material-components/material-components-web

streetcomplete/StreetComplete#1130 (comment):

Once, we've got this, maybe first add some sketch (via Inkscape?) so we have a common vision of how it should look like

Tools

• Put Inkscape file in repo here, I guess.
• For drafting, just use this issue?
• Or https://www.draw.io/? (But as far as I see, one also cannot collaborate there.)

What?

First finish #5 and #6. If we are sure about what it should look like, let's make a simple sketch on what should be placed where, how will we prioritize stuff, what should go right/left/top/bottom/etc.