Website landing page revamp

“this can be achieved without Javascript?”

For a browser old of 30 years? :smiley:

On the screenshot of the T-shirt:

I think there are too much rounded buttons and rectangles, hiding the most important button: Download button.

Maybe use a unique color (background-color) for the Download.

@webDev first of all, your drafts look really good!!!

is somehow invisible. Personally, I prefer the “strict” separation of menus/footers from the actual content, but maybe I’m from old school :blush:

Yes thansk, I saw it.
I’m fine with dark-glass effect, but isn’t one superfluous? Why two buttons practically side by side?
Someone mentioned that F-Droid has only an android version. So, “Download F-Droid” is sufficient (imho).
Based on the F-Droid icon (shadow), I have changed the perspective of the button.

Personally, I prefer the sketched hand and not the real picture, but it’s a little detail.

You can maybe play around with my new mockup (only one download button and w/o hand):

Personally, I’m absolutely against including any third-party stuff. If so, then only locally. Though, there can be some downsides.

There’s a similar discussion at signalusers[dot]org:

@webDev Very nice looking! :tophat:
Even more interesting that you used a tool like Inkscape to do this. Do you use it also for more final visuals or just for these very good looking initial drafts?

(…merging here)

I think dark orange would suit well 9 years old F-Droid : strength + endurance (?), versus blue ( cool + fresh ?).

@webDev , there are few I don’t find in your artwork :

  • android is now heavily focusing on multi screens : auto / tv … (and so should F-Droid ?)

  • vocal command emergence (no hands required)

  • reproducible-builds

(Back to orange,) F-Droid is not explicitly Gitlab dependent, but it seems there is no other “viable” solution to maintain the whole project. So orange could link to Gitlab without need of mentioning it (?). Also there should be somewhere a permanent “bridge” to encourage users to become Gitlab active members (especially for missing metadata ?) ?

1 Like



  • Social icons
  • A Privacy page with instructions on how to access Privacy apps from Guardian project, and how to setup the Panic mode, a link to encryption apps, a link to other privacy resources? (More on this is mentioned)
  • (EDIT: Add RSS icon to social/community icons in nav)
  • (EDIT: Maybe add a ‘Tell a friend’ pane (see below))
  • (EDIT: Reduce contrast and arc/circle numbers in top artwork (see reply #49 below).)
  • (EDIT: add a “Javascript is enabled in your browser. Learn about how JS may impact your device and privacy.” message to users who have JS enabled in the browser?)

Mobile (click to see full page)

Mobile menu


Desktop menu

@shubhamtyagi thanks and agree. A download button at the bottom is important.

@hotlittlewhitedog, there are security and privacy reasons for blocking JS.

There is no DL button in the donate region, look closer ; ). I tried removing the rounded donate buttons but it made the pane look very cluttered, interestingly.

@fd-fan, sounds fair. I won’t include Font Awesome.

The problem with the distinct separation is it make the top message appear cramped.

@ggruber, inkscape is pretty great, despite a few issues, I plan to use it to the end, : )

@oF2pks, I like ur idea of using design motifs (in this case colours) to link F-Droid to Gitlab. The problem is blue is a good, calming colour for F-Droid. Keep in mind with your design that colours in different proportions can do different things. So an entire wall painted orange has a different effect than a few small elements in orange. I feel like over-hauling the logo is a bit outside the scope for this project. All I did is shapern a few bits and add a shine. What would be good in the future might be a design competition to develop a new robot. The new robot would need to get a 70% approval rating over the existing robot, to justify the change. As I said before though, you dont need to worry about the blue colour damaging your screen because F-Droid doesnt need to be on your screen, especially for a long period of time. If it really bothers you have you tried talking to the people who make that Amexia app? They might do a version in colours that are less damaging to screens. I’m interested in learning about this problem myself. Might you please provide a link to the scientific studies?


  • “Latest” jumps to the newspaper-style pane down the page.
  • Hamburger (three-dot) menu / footer
    ---- “Privacy” links to the same place where “Learn more” goes to in the purple/Private section, TBA. Maybe if a page doesn’t exist for this, then we need to make it? Simple tutorial page on how to enable the Guardian Repo perhaps?
    ---- “Download” goes futher down the page to the FDroid screen.
    ---- “Contacts” goes to the ‘About’ page.
  • “FAQ”



  • Update home page image(s) here:
  • (EDIT: Rework the ‘Design’ section on the ‘How to Help’ page ( to refer not to specifically redesigning the landing/home page, and to refer more to continual improvement.)
  • Update search results page to be less white? Three apps to a row on large displays, two app to a row on medium?
  • (EDIT: add a “Javascript is enabled in your browser. Learn about how JS may impact your device and privacy.” message to users who have JS enabled in the browser?)

For pages that are not the landing page, I am keen to keep the same layout (ie. content in the wider left column and news, donate, and latest content on the narrower column on the right). The top navigation bar, language and App Search functions may be updated to match this landing page.

‘Docs’ page (
Slight rework may be desirable:

  • Docs => Documentation?
  • General FAQs could be on this page, but collapsed (checkbox hack to reveal them without JS).
  • App FAQ could be on this page, but collapsed as above.
  • Tutorials could be listed on this page under a “Tutorials” heading, thus completely eliminating one page load/click.

‘Security Model’ page

  • Grammer (minor): A comma at top of page has white space before it. Therefore comma can (and does) appear on a separate line.

EDIT: Wiki page (

  • This page is interesting. Its about redesigning the home page! The writers had a different approach to explain in greater detail some of the abilities and features. We should seek to ensure that all the information that is presented (and still valid) here is featured within the FAQs ( If no one volunteers this then I will do it another time and re-edit this reply to list the recommended changes. Some of the info on this page may be obsolete, or self-explanatory these days but not all of it. If the content on this page is updated a bit it may be useful today on a ‘Tell a friend (about F-Droid)’ pane. The text could read, "F-Droid is 10 years old and has become a trusted, FOSS app repository. Share your passion for FOSS apps and [get your friends and family up to speed with F-Droid]. On click, a text area appears with words, “Copy/paste the text below into your message.” (??? EDIT: Thoughts on this ???)

@oF2pks The orange looks a bit brown I think (sorry).

And it might be that we have to (or want to) get away from GitLab in the future.

Finally, personally I would not understand that you are referring to reproducible builds (again, sorry).

I really like your ideas and work! I only think that it looks a bit too crowded, maybe take out some of the twirls or decrease the contrast? (just my personal opinion).

Maybe you also want to propose a redesign for the client? I tried to start something here but I am a developer, not a designer.

Thanks Hocuri, will reduce contrast (whiter items to grey, darker arcs will be lightened). Will also reduce arc and circle numbers, where possible. Adding this task to the TBC above.

The more creative designs means the more creative the business is means more customers automatically create lifelong relationship with business.

Hi Ashish, I although I rarely advocate lifelong relationships with things, except maybe stainless steel cookware, I feel that the more people using FOSS and privacy apps the better, for numerous reasons.

Hi folks,

I whipped up this “Tell a Friend” section based on the F-Droid wiki page that I wrote about in the last comment I made.

If people think it’s tacky and too “advertisey”, I don’t need to make it. But remember, that wikipage was translated into three languages and I think it could be valueable presented to users in this way, with a bit of updating because the page did have some old info.

Also I think we need a way to celebrate 10 years so just putting this out there for critique.


Has the “searchpage” also been considered? imo, this is “more” important then wikipage :thinking:

@webDev I think your designs are looking good! Are you also planning on implementing them? That’s the surefire way to make sure it gets built. I can review merge requests as time permits.

A couple things to think about:

  • the work should be broken down into useful chunks, so that they can be merged and deployed once they are done.
  • Since free software contributions are not predictable, each merged state should be usable as is. Staging/beta most likely needs to happen separately from merge requests to master.
  • the icons should probably be Material Design icons so they match Android, e.g. the languages, home, search, etc. They are all freely licensed.
  • all assets need to be hosted on, no third party servers
  • we could include ForkAwesome as needed, IMHO

I’m glad you have the same opinion.

In response to my concerns

webDev wrote:

1 Like

@fd-fan, I’m unsure that the search page ( a good page to lead people to because it is so sparce. I think its better to have a search form on all pages This is the way the current site functions although I hope to improve the user experience. You’ll see in comment 47 (49th counting spam) I have added a “Find apps” form in three locations:
1)The top bar,
2) The top hamburger/three dot menu, and
3) the footer.

@hans, Yes I will be implementing it. I have a bit of learning to do about Markdown first as I’ve not used that before. Unfortunately, I don’t think that I am currently in a position to do the “Hugo transition” as I’m not familiar enough with the current setup. After I do the landing page I may be inclined to do the Hugo transition but intuition tells me that it probably won’t be easy.

  • Re staggering, the top ‘menus’ and ‘latest’ panes will take the longest to implement, the rest are fairly basic. Therefore the only thing that I could realistically leave till last is the ‘latest’ pane. So I’m thinking we could do it in two stages. For the ‘latest’ region, all I’d need to do in the interim is put the ‘Updated apps’, ‘Latest apps’ and ‘News’ columns as distinct medium-col-4’s (I’m assuming bootstrap CSS is fine but JS isn’t)
  • Possibly in a third stage I’d like to add a “You have Javascript (JS) enabled. Learn about how JS may impact your device and privacy.” message to users who have JS enabled in the browser. We would ideally have that “Privacy page” done beforehand, centered around Privacy apps, the Guardian repo and the Panic feature, a link to encryption apps, a link to other privacy resources etc. The new landing page is intended to have a few links to this Privacy page so it should be done before the merge. (Will add this idea to the list in comment 47).
  • Re icons, I based the design on the fact that it needs to work in Tors highest security settings, therefore the icons will need to be rasterised, not svg nor fonts. I’m not hugely familiar with Material Design icons yet. I based my icon designs on the existing apps and the style of the Font Awesome, other nice icons I see etc. Also we are in luck, it appears that the ‘srcset’ attribute of the ‘img’ element is now widely supported. So I am looking forward to using that to deliver appropriately-sized and compressed content to different displays and retina resolutions.
  • Re assets served only from, yes that has been my intention throughout, so gotta try and keep it light.
1 Like

@NicoAlt Hi mate, was doing some exploration of Markdown, this ( is a list of static-site builders that build from Markdown. The “Hugo” build tool is listed and is shown to be written in Go. Does F-Droid allow Go built apps? I don’t actually know. If it doesn’t then we probably can’t use Hugo, by extension(?).

Hey @webDev,

Haha, yeah. F-Droid’s unique requirement is that software is free and open source, but don’t get confused with apps inside F-Droid and software used in its infrastructure. I’ve never heard of “Go built [Android] apps” and I imagine it would be a pain to build them. For the infrastructure, any language is fine. Only in case we have two equally qualified pieces of software, one written in python and the other one in some other language, we opt for the python one. But Hugo is really the best static site generator out there, so that’s the way we should go. Also note @hans’ comment on the issue linked in this topic some days ago:

Moving the blog only to Hugo via the site shouldn’t be a lot of work, since it is basically already running. Moving the whole site to Hugo is a project, perhaps not huge, but a chunk of work. It would very likely let us remove the limit on the number of languages. It would also likely greatly reduce the server specs required for generating

This together with Hans’ last post here should give you all necessary information to get on speed. Thanks a lot for your work!

Overall, sounds like things are progressing in the right direction! I’d just like to add one comment about Javascript libraries and security. Most F-Droid contributors are not web developers, though some are. I’m not, for example. So I don’t have a good sense for how to evaluate Javascript libraries for security beyond just standard practice things like include as few deps as possible, and use libraries that have well maintained stable releases. If there is bad Javascript in the site, then an attacker can change the initial download link, e.g. the big download button on the main page. That can then be used to feed malware versions on a targeted basis, or other bad things.

You’re probably looking for Subresource Integrity, an underused security feature for frontend. That alone solves most dangerous holes in client JavaScript.

@Roboe that’s a nice feature for ensuring that the javascript files are delivered unmodified, but it won’t help at all if the original Javascript library has vulnerabilities or even malware in it. I’m talking about the latter case.

And for the record, we solve the issue of javascript sources being reliable by always sourcing them from our domain. No other domain is allowed, check the HTTP CSP.

1 Like

I meant rather whether it was “considered” that the search results/list would also be adapted to the new design.