Launch re-done website ASAP, marking under construction?

Clearing the Path
1

Today during the meeting the idea was floated to consider temporarily taking down the website as we replace it with a new frontend. We would have a clear ‘under construction/maintenence’ notice that pledging and auth is down until we can connect the functional backend with the new frontend.

This approach would unblock iterative development of the front end, and that is a high priority to solve.

We could also have both sites running via a subdomain or similar and use redirects to go back to the older site as needed, updating the redirects as the new frontend gets finished.

This will be a topic for the @team to contemplate and discuss (especially at next weeks meeting

Please take the time to think about the ramifications and issues so we can discuss this constructively.

Thanks everyone

Tracked at: Update website tech stack to un-block development (Elm rewrite) (&5) · Epics · Snowdrift.coop · GitLab

3 Appreciations
2

After some time to mull this over, I think I’m against replacing the old (current) site with anything before the new site is ready. However, I still think we should put the new site live soon. Specifically:

  • Put up the new site at https://new.snowdrift.coop
  • Each time a page is ready, change the old site to redirect to new. — one page at a time
  • Once the new site supports login / SSO and changing credit card info / (un)pledging, take the old site offline and move the new site to https://snowdrift.coop.[1]
    • Note: these features are the ones that require backend integration.

Other opinions — I think that…

  • The new site should have a prominent header announcing that it is under construction.
    • It should link to a page that explains how to help with the update effort specifically. Maybe a blog post or a GitLab issue/epic.
  • We should start by implementing the home page.
  • A hackathon-esque weekend would be very useful to get started on backend integration.
  • If we want to change the forum categories any further[2], we should do it before putting the first redirect in place, since I anticipate visible progress on the site will result in more attention/activity than normal.
  • Initially we can host the new site on GitLab pages. It’s actually already there, we just need to request the OSUOSL to add a dns entry. At the same time, we should start working on deploying the new site from OSUOSL infra, since that usually takes a little time to set up.

  1. Optionally, we could also set any page at new. to redirect back to the bare domain. ↩︎

  2. Which I do, but I'll talk about that later & somewhere else. ↩︎

2 Appreciations
3

I still prefer to try to use old.snowdrift.coop and just snowdrift.coop (with missing URLs falling back to the old version), because then I only need to make rapid changes in one repo.

But it’s no big deal if we all want to go the other way. (I don’t know how to do the redirects in yesod, but someone can take that job). But then, given that people won’t land on new.* without trying to, the big “under construction” sign seems less important.

1 Appreciation
4

My main concern about old.snowdrift.coop is that I don’t know whether anything additional will be required to keep Single Sign-On with the forum working, whereas I know how to add a redirect in yesod (like adding a file but with a redirect instead).

Otherwise, either way seems fine. If we went with old., I think I would still be inclined not to redirect, and we can mention the old site’s location in the header, blog post, and/or 404 page.

5

Yeah, I knew about that uncertainty, so I guess you’re saying you still don’t have information on what’s required to keep it working. I figure this kind of question needs to be answered no matter what, since we’re about to build that very thing anyway. But if it’s really gonna be annoying to migrate, then yeah let’s not touch it.

6

I did a quick peek into the discourse settings and it might be as simple as changing the SSO endpoint. I don’t mind trying to move the live site to see if that’s true. If it works, I’m fine using old.; if not, I don’t want to let it be a blocker on getting the new site up & running.

2 Appreciations
7

In our meeting last Tuesday, @mray raised an objection to adding redirects, rather than leaving the current site as-is until the new one is ready to replace it. We’ve decided to postpone that decision until at least the first page is implemented. That page will be /projects, since it is one of the simpler pages, already has a mockup, and is unlikely to receive (many) changes in the mechanism v0.3 update.

1 Appreciation