Refactor Redesign Code

[VirginiaBalseiro]

This PR is co-authored by @csarven .

This PR mainly covers refactoring the proposed code for the new website design, in order to simplify code and facilitate maintenance and contributions. It uses semantically correct HTML; removes CSS libraries and JavaScript.

Issues/Regressions

This is just a high-level summary and not an exhaustive list of issues or regressions. We were able to identify various areas where more attention and additional work is needed.

• UX/IA: In order to cover both the structure and design of all of the webpages on the site, it would help to have proper UX and IA documentation, such as:
  • It would be useful to have a style guide to ensure that the design is consistent, reproducible, and reusable.
  • It is important to have a sitemap of all URLs under solidproject.org to ensure there is a record of everything, as well as the intended level of persistence for each resource. We will create an issue to track and introduce in later PRs.
  • We did not have mobile designs, so we decided on layout that made sense.
  • It would be useful to have a documentation of all components that are reused across the site's webpages, as well as structure (field/value) for each significant unit of information.

Notes on implementation

• The implementation of the design is not pixel-perfect and there are still many things to fix in the CSS (padding, font styling, etc). We decided to PR what we have and make subsequent PRs with improvements.
• We added https://solidproject.org/terms but we did not have a design for this, so we reused the general outline of the proposed design and migrated the content.
• "Users" sections are not in the current design. We're planning to re-introduce the sections in an upcoming separate PR.
• email-only contact point conflicts with previous decisions, e.g., Changed instructions for updating Pod providers, so we included the GitHub PR option to be added to the organizations list.
• We recommend accessibility tests on structure and design. We will follow up with issues/PRs.
• No JavaScript was used in this release. text-based Web browser and archive friendly.
• We prioritized using more generic selectors before resorting to classes, but we will continue to improve the CSS code and might introduce them and make other changes on this front. We used a mobile-first approach.
• All src, alt, href etc. values need a pass/review.

Just some linked data stuff of the documents here... no big deal:

[csarven]

Thanks for reviewing @KyraAssaad . I'll try to respond to your comments here, let me know how this sounds:

As you've noted, there can be more classes (or essentially any recurring selector). Thus far we tried to identify and markup common / recurring data patterns based on the proposed visual design, and a bit from the current website. But more work there is needed. And, to get there, more pages need to be marked up and/or refer to a (IA) document specifying the classifications. This will also ensure updating the information consistently with a (Solid) application, especially with the inclusion and help of RDFa.

In some places we tried to reuse patterns, and as you've also noted with things like details. Whether that structure and semantics remains or not depends on distilling the underlying data patterns. Either way, the CSS can take care of the default details (to be [open], and hiding summary) look whether it remains in the HTML or not, and the dts can be hidden from the visual representation. ul and dl is used quite a bit as it helps to maintain structure to significant units of information. It is also accessible to text-based web browsers. And, if/when a design needs to show any particular dt (for instance), only the CSS needs to change. The intention is to reuse the data patterns in HTML as much as possible throughout the pages (including new ones).

So, I think once the recurring data patterns are fine-tuned, it is easy to settle down the view.

[timbl]

Thank you for all this great work leaving the site declarative. I approve of the direction. I hope that we see this deployed soon. The the cost of having the old design up is significant I think and so switching to the new one before it is perfect may be optimal. The sooner we switch the sooner we get user feedback.