@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.
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.
@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 f-droid.org, no third party servers
@fd-fan, I’m unsure that the search page (search.f-droid.org) 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 F-Droid.org, yes that has been my intention throughout, so gotta try and keep it light.
@NicoAlt Hi mate, was doing some exploration of Markdown, this (https://www.staticgen.com/) 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(?).
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 news.f-droid.org site shouldn’t be a lot of work, since it is basically already running. Moving the whole f-droid.org 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 f-droid.org.
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.
@fd-fan , oic, not at this stage, but I just checked the search page and yes, its is a bit too white actually, I’ll put this in the list above, as something to do after the landing page. Not sure what people think about having the search results being three to a row on large displays???
I did notice the clever “Open Search” system in the header too btw so will not be interfering with that.
The CSS seems nicely written btw also, nice job @NicoAlt I saw your name in there : )
(EDIT) On second thought, I probably don’t need to be “online” much during development. Will try to develop the page “offline”. I assume that I will need to install jekyll on the machine to build the page? Is there a particular IDE that I should use that plays along with Jekyll, Markdown to build individual pages that are changed?
Oh, I didn’t really do anything over there, just translated some very few strings and removed all third-party requests. But nice you like the CSS!
In general, that’s right. You install ruby, bundler and the other dependencies while you’re online. Afterwards, you are able to build the website offline, excepting the F-Droid app index. There’s currently no cache mechanism for this and therefore needs to get pulled on every build.
I don’t know of any. Jekyll is really bad at incremental builds and therefore you need to build all the thing again on every change. You can speed it up, though, by removing every language excepting English and by removing the jekyll-fdroid plugin in the configuration.
Thanks for the continued work on this! I guess you then have to decided to stick to Jekyll for the moment and not go with Hugo?
Regarding your wifi connection problems, I think you have an issue with your wifi driver. Did you try a wired connection? I had similar problems in the past and fixed them by searching for my wireless card/driver and disabling some power saving mode.
@NicoAlt Yes, I’ll stick with Jekyll for the moment
Thanks for the tips! Will ask if I need further pointers.
Yes I thought that the wifi problem must be related to the drivers but I read somewhere that Ubuntu had drivers built in. I’ll try again to get to the bottom of it…
EDIT: Fixed the personal wifi problem!! It was indeed the power saving feature, @NicoAlt. What sux is that it was on one of the pages that I tried a couple of possible solutions from, over a month ago. I just needed to try a few more of the solutions. Ugh. Feels good to have that fixed, it was driving me nuts. Thanks and will be back later in the week.
You can find the exact setup used to build the website in .gitlab-ci.yml. It is currently based on Debian/jessie, and needs to be updated. Let me know if you have problems building it, it could be a good excuse to update the build process to run on Debian/buster.
