D4.1 -- DREAM public collaborative website

DREAM WP4 - REPORTING
, ,
11

background suggestion: #fff6d6 – I prefer lighter/warmer/less prominent colors as background – I took the lemon curry color from there and made it lighter

12

The <iframe> in there shows:

Blocked by X-Frame-Options Policy

An error occurred during a connection to ps.zoethical.org.

Firefox prevented this page from loading in this context because the page has an X-Frame-Options policy that disallows it.

13

also, I like this palette: https://github.com/morhetz/gruvbox#light-mode-1
though it looks already good just by using the lighter background i mentioned above,
perhaps the blue could be changed to #076678 from this palette
and the button background to #9d0006, it has too much contrast currently

14

Thank you for reporting! This comes from the SSO with ps.zoethical.org. I should add it to the CSP headers.

I’ll be working on the website this afternoon.

15

I like the direction you’ve taken the design of the website, @how.

Especially happy to see you using semantic HTML and modern (but uncomplicated) CSS patterns such as variables, to keep things clean and easy to maintain.

I mentioned this in our chat room, but in case you missed it, I would love it if you took a look at the website I made for my NLnet-funded project “secushareBOX”:

The source from which the site is deployed is here:

It may be directly useful to look at the way I did the “responsive” CSS so that it adapts to every screen size (including mobile screens).

1 Like
16

Another fun thing to note on the box.secushare.org site is the “tooltips” which popup when you hover over the bold text with the dotted underlines.

Please note that there is no javascript used anywhere on this website. :slight_smile:

1 Like
17

I like your approach @dvn. We use similar minimalist techniques. I did not use CSS Grid this time.

In the latest installment which just went live, I prepended the CSS with Normalize.css: an oldie and goodie that remains a user-made fix to browser differences so that the site appears about the same across browser vendors – hopefully: I did not check yet.

There are still a few known issues:

  1. no support for vendor-specific CSS attributes (esp. for flex items, e.g., there must me some --webkit-foo-stuff lyring around in older versions), but maybe I’d like bug reports for those :wink:
  2. the topics list inclusion could be bettered. I’m especially interested in considering including all Work Package reports and making the titles stand out a bit more.
  3. the button links lack contrast (OK, you can see the flame color, but the text color lacks contrast)
  4. I find the contents lacking a bit for a home page. But do we really need more? Maybe download links, links to specs, etc. when we have them. It would be easier to think about it in advance to be able to add them easily…
  5. The styling of the pages behind, served from Discourse, should match this one.
  6. All contents should be made public at some point :slight_smile:

Did I mention the source code is at dream.public.cat.git - Static Web for Digital Replicated Edge Agency Machine

18

Another minimalist approach you can see at p2pcollab.net.
It’s using pandoc with Tufte CSS and a pandoc template, and a Makefile that generates html from org/md files. I’m planning to look into AsciiDoc and make a similar template for it.

19

I like the minimalist way of @pukkamustard to generate the site:

20

First impression feedback from a friend on the content of our website, which I’ve distilled into some points:

  • Lots of buzzwords/lingo
  • Unclear if the group will be distributing (3rd party) end user applications, or developing them, or simply developing a decentralized framework for existing collaboration apps
  • Not sure what level the work is being done at.
  • What is the relation to MirageOS? Is it a fork?
  • Is this a containerization system for a decentralized cloud?
1 Like
21

How do you think we should address these points?

22

I have some ideas. Will share later. Maybe in person first. :slight_smile:

1 Like
23

Some notes on the discussions on the website at the end of our week-long meetings:

  • Explain what is peer-to-peer from scratch? What are the points and uses of P2P (Preservation of data)?
  • Explain what group collaboration is in the sense of the DREAM project.
  • Explain “Open Knowledge” (in a tooltip definition?)
  • Change “We design networks and systems” to “We’re designing a system to…” to be less broad, more precise, and sound less like a corporation looking for work.
  • Display the timeline of the project deliverables on a page of the website.
  • “Organizing peer-to-peer” is not clear enough.
  • The website could use some definitions in tooltip of words
  • Write out “peer-to-peer” instead of “P2P”
  • “In 2021, we will research” could be a link to the timeline of deliverables.
  • Put the “NGI Pointer project” in a footnote, and use “An European research project” with a link to the footnote.
2 Likes
24

Yes, I get your point re: AsciiDoc(tor) vs Markdown. It should not be difficult to configure Nginx to serve an HTML generated from AsciiDoc instead of the Markdown file from the referenced URL. In this case, the ADOC files would end up in the dream.public.cat.git repository. We simply need to figure out a way to build them from source and output the wanted HTML at the right URLs. It should be straightforward. My plan last week was to include the nginx.conf anyway into this repository.

I propose that in the meantime you keep working on AsciiDoc documents until we set up a proper publishing workflow, and reference those files from the first post, so we can publish the links already – they will be indexed in search engine early, so that they’ll gain SEO over time. Once we have the final versions, we can simply switch to the HTML files (since nginx will serve static files in priority, skipping hitting the proxy for dynamic content).

Should we include the 6kly-cycles image in the web site somewhere?

1 Like
25

Deployment Script Fixed

#1 was fixed with this comment:

This was fixed in v0.3.1. The fetch command from the bare repository would not update the checkout , so I had to add the fetch refs to ensure proper update.

The only problem left is that updates to the dream-api.lua file are not automatically updated. Two steps need to be taken:

  1. copy the script from the checkout directory to /etc/nginx/scripts
  2. reload nginx.
1 Like
26

My screen is slightly unusual, and when I looked at the website, the left part was not visible (so part of the word design). When I make the screen even smaller, more things are not in the right place.

27

Yes @pukkamustard, there’s still no proper way to do it, but we can decide where it should go and stick to that.

For example, we could host the HTML docs under /doc/<project>/<package>, e.g., /doc/dmc/ocaml-dmc. BTW, should we stick to the Dromedar name or switch to DMC?

Then we can add the generated files to DREAM / dream.public.cat · GitLab (or better, have a Makefile that fetches the artifacts from Gitlab CI and add them to the repo. That can be a solution.

Note that in any way, /pub should be avoided (as /c, /t, etc.: whatever Discourse uses). Apart from this it’s fine. We should even put the nginx.conf in there so it’s picked up by the server – but if we do this, then we should as well move everything under etc/ and public/ for example to avoid having the server configuration in the web root.

1 Like
28

What size is your screen @arie?

29

I’m on a different screen now, but with 950 * 1350 (or ‘more square’ so decreasing the 1350),
it starts losing some text on the left.

30

Cool. No strong opinions on exact paths, I’d gladly leave it to your best judgement.

1 Like