Launch the 2023 redesign #876
Conversation
michielbdejong
force-pushed
the
2023-redesign
branch
from
6bb9f64
to
cbb57a9
Compare
… (May 2024 rebase)
…recommended for git-handled repos
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
For website development
Co-authored-by: Ted Thibodeau Jr <[email protected]>
* WIP: refactor HTML/CSS Co-authored-by: Sarven Capadisli <[email protected]> * HTML corrections / alignment for index, about * consolidate stylesheets, minor fixes * Update homepage img alt for article * Minor * Remark for-developers * Remark for-organizations * Add contact possibilities for orgs * Update pod-provider and research-institution blocks * borders, minor CSS changes * Use details for whole video figcaption * Minor * CSS fixes, WIP * Add Terms * Minor * Update community * Use /about * Add redirects file * Add some DOAP about Solid Project * Remove unused reference * Add ethicsPolicy to Solid CoC * WIP styles for community page, mobile * Minor * CSS fixes * Adjustments to events details margin/padding * Padding, lists styles * Padding * Update hosted-pod-services listing markup * Update events markup * Hide dt in hosted-pod-services * fix about page file extension, inline widths, image alt text and role * Adjust font-size in pod providers list * Update alt/role * Minor --------- Co-authored-by: Sarven Capadisli <[email protected]>
This reverts commit 0ba79a5.
Some resources are removed altogether though, and I don't know where to point to on the new website.
Resolves #859
michielbdejong
force-pushed
the
2023-redesign
branch
from
cbb57a9
to
1d56403
Compare
|
Main: |
|
Let's merge this during the 8 May Solid Team meeting If you have any changes to add, please create a PR against the |
|
looks fantastic, if you ask me. I'll try to be there..... |
There was a problem hiding this comment.
Let's merge this during the 8 May Solid Team meeting
I don't know i I will be able to attend this meeting. I have objections to merging this as is, and I don't know if I will have the time to add my review before then. There are a number of concerns that have been raised and have not properly been addressed here, as well as other changes this PR introduces that are inappropriate, like completely removing the website strategy document.
I am requesting this not to be merged until this PR is properly reviewed and discussed by members f the Team, especially those closely involved in this particular project (see https://github.com/solid/team/blob/main/tasks/solidproject.org-development-maintenance.md).
There was a problem hiding this comment.
Michiel, thanks for creating this PR to move things forward.
Let me first say that my concerns here about the Solid Team management / process / redesign as a whole, and not specific individuals or subgroups, or even the minute technical matters. We can improve the state of the work. But as things stands, I strongly do not recommend launching this work due to several reasons (some mentioned below).
There are a number of concerns with this PR that I'd like to highlight - it is not intended to be exhaustive.
It breaks good practises on maintaining "cool URIs" ( https://www.w3.org/Provider/Style/URI ). Sorry, I can't make the case for cool URIs in 2024.
https://github.com/solid/solidproject.org/blob/main/website-strategy.md#sitemap was introduced in #856 because it is the only thing that legitimately tries to track the assets of the solidproject.org website. It is "living information" that needs to be kept part of website maintenance.
That said, I'm noting that website-strategy.md is being proposed to be removed in this PR, which I'd like to recommend against. I recommend a proper walkthrough of website's sitemap - actually filling out the table with justification on what/why - before launching the website. Those that feel strongly about any row on the table as to what should happen, please refer to specific issues, decisions, explanations, and so forth, so that here is common understanding on how the website should be maintained over time.
- Related to the above, there is still no proper documentation on IA (Information Architecture) and UX (User Experience) or actual design guides.
- Resources that are being introduced shouldn't use
.htmlin the path. - The "redirects" based on HTML script are inadequate for non-JavaScript based agents, e.g., crawlers/indexers, archives. As far as HTTP is concerned, the responses to requests will still get
200OK. - The way the "redirects" are used here are not meaningful or even correct way of using redirection. In a nutshell: none of these presumably redirected resources are actually available a different URI. For example, the identity of the resource "newsletter" can't be found on the resource identified for "homepage", and the list goes on.
- Drops resources, e.g., license, faqs, newsletter (for historical record).. but this is just a fraction of things.
Again, I can't justify the importance of cool URIs in this PR comment. Either we acknowledge that and work towards it (sitemap) by being a good host or say "we don't care" or pretend it is a non-issue - the current situation comes across as the latter.
The initially proposed 5-page static design with next to no documentation was a non-starter - and this was communicated a number of times to the Solid Team - and the fraction of issues we've already dealt with in this repo (and redesign branch) to improve the situation is a testament of that. After all, the proposed work virtually tried to remove everything, e.g.,:
- the "Terms" page, at the very least pledges a URI persistence policy. The Solid CG uses the
/TR/path for its specifications. Many things out there, from random webpages to research articles refer to these resources. - the for Users page was removed... but then the for Organizations page was introduced. There is no justification besides being literally counter to the whole project in that Solid's aim is to first and foremost to empower users.
It was rather awkward to have to make the case that the website needs to be welcoming to "users" ( #859 ). And need to raise a point like ( solid/team#72 (comment) ):
The team has resources to update the events page and somehow identified and allocated new resources for adding "For Organisations" but ceases to have resources for updating the page for Users and Apps?
That's on top of the fact that contributions to those Users pages are distributed, as opposed to Solid Team actually being the only group maintaining it or worry about being limited on resources to maintain them. It is literally self-maintained. That said, the Solid Team supposedly wants to introduce maintenance on For Organisations? I hope I don't have to spell out why that is both a strange "redesign" "decision" but inappropriate at this point, but I can if anyone would like me to.
There are minor technical concerns here as well as broader conceptual and process related. I'm not concerned that there were accidental deletes during WIP (or that the redesign wasn't well thought out) nor even that the Website Task Force team caught the issue and resolved it before it became an actual problem in the wild ( e.g., #836 , #863 ), but the fact that the so called "redesign" had not taken any of these things into account or a way to systematically address them. We are working with a limited design given as a packaged deal.
Again, the website "sitemap" ( https://github.com/solid/solidproject.org/blob/main/website-strategy.md#sitemap ) is a way to approach these types of concerns in the process of updating the "design". To literally know what's going on with the website's assets. But this PR even proposes to remove the sitemap from the repo even after the fact that it was deemed to be necessary when introduced in: #856 .
Again, to date, there is still no useful IA / UX documentation. We are at best arbitrarily making things up as we go - without working with the community - but actually introducing a tonne of issues that didn't exist in the first place!. That's by regression by definition.
There is no data on how the proposed redesign is an improvement on the current design. However, there is data on why the proposed redesign is a regression. The sooner we acknowledge that, the sooner we can actually find ways to improve the state of things. I can understand that may not be what we want to hear but that's where we are at.
The website first and foremost needs heavy content editing, not "redesign" without proper IA/UX work in place. If we want "redesign", then we need to take it seriously and actually improve what we have.
The community is in fact contributing and maintaining pages like apps and tools, e.g.:
- Add Umai to apps listing #815
- Update apps.md #871
- Add migration instructions for older apps #607 (comment)
- ...
and even descriptions/definitions, e.g.:
among other things.
I see no direct resolution or acknowledgement of the issues or the contributions. What I see here is undermining of that work. I think we can do better and should make more effort to work with t
Incomplete:
And there is an ocean of issues outlined at https://github.com/solid/solidproject.org/issues about the website that have no specific response to those issues or even an agreement / understanding to work with the community.
There is not even a response to the review that's given on the proposed design:
It'd be great to include some documentation on the proposed IA and UX changes so that we can both understand and monitor what aspects of the website (structure, content, design, or other) are changing, and how they may or may not affect existing issues/PRs. Furthermore, it'd be great to have any user survey or testing to support the design when UX is mentioned.
Again, we are working with a packaged deal. Are we to communicate to the community that with the redesign launch, all of those concerns are now resolved?
I couldn't agree more with some folks that have already independently voiced "what a mess". We need to, and can, do better here but that's not something we can easily resolve through this PR. Being crystal clear on openness and transparency can't be undermined for the Solid Project. Perhaps we need to take a step back and have our principles and values in place: #835 and abide/pledge because otherwise we will indefinitely run in circles. And of course it goes without saying the issues/PRs in the Solid Team repo: https://github.com/solid/team/
Deep breath.
All that aside, it saddens me to see contributors (from the Solid Team, Website Task Force, in fact) being so discontent with the process/management (partly related to the redesign) that they no longer want to be part of it, e.g., solid/team#75 , and there has been many others in the past departing ways for fundamentally similar reasons. We ought to find ways to better unite and grow.
LGTM! |
|
@VirginiaBalseiro hi! sorry, I wasn't aware that you had objections to merging the redesign as is, otherwise I wouldn't have proposed doing so. Please take your time to open github issues and work through them before the next team meeting. Regarding the website strategy document missing from the branch I already created #878 just now, but maybe you have other issues you want to get resolved before the merge. |
|
@csarven hi! thanks for your long comment.
Please, create one GitHub issue per concern that needs, fixing, please make sure that the list of GitHub issues you create is exhaustive (otherwise there will always be new objections popping up on the day of the launch and we will never get it done), and please actively participate in getting each issue resolved. I will do the same, and I hope other team members and community members in general will too. I'll close this PR now so the website task force can open a new one, and have a new launch attempt, maybe at the next team meeting on 12 June, maybe some other day - I'll leave it up to you from here on. |
No description provided.