search

dweb-camp-2019 / organizing

Repository for the organizing of Decentralized Web Camp 2019 🚧
https://dwebcamp.org
20 stars 2 forks source link

Design + deploy + p2p-publish the Camp 2019 website #13

Closed benhylau closed 4 years ago

benhylau commented 5 years ago

Create Scope of Work, Contract for PE Area.

gobengo commented 5 years ago

I may be able to help with coding and even hosting. I would not call myself a very good designer, but very proficient with CSS so can help implement from a mockup

benhylau commented 5 years ago

Hey @gobengo we started some chats listed on https://github.com/dweb-camp-2019/organizing for more real-time communications and some new repositories to better organize things. Hope to chat on there.

@whanamura do you have updates re: website stuff? I remember you mentioned someone is working on design?

whanamura commented 5 years ago

Hi @gobengo Sorry for the lag in response! Organizing through GitHub is new to me! I just lined up some terrific designers: PE Area (Lexi Visco and Calvin Roccio). Here is their Scope of Work and timeline: https://docs.google.com/document/d/1wGY_Ga1yYFhCXlGQFk_xq2qYZYsWAk3qaWoUy_sV3WE/edit

We can use help implementing their reskin in June. And maybe come help bringing over the current site CMS & Database (decentralizedweb.net) to the new URL (Dwebcamp.org).

If either of those tasks sound viable to you, we'd love to talk!

gobengo commented 5 years ago

I've been overstretched volunteering in the last few weeks and need to get back to other gigs. I can't be relied on for those tasks.

I encourage you to publish the output of that design process out in the open though, as it'll make it easier for volunteers, whoever they may be, to help and collaborate.

Same thing with other information:

In my experience implementing a design for a CMS is at least 5x at time consuming as just implementing the design in HTML/CSS/JS. But it's been awhile.

benhylau commented 5 years ago

In my experience implementing a design for a CMS is at least 5x at time consuming as just implementing the design in HTML/CSS/JS. But it's been awhile.

+1 consistent with my experience

whanamura commented 5 years ago

Thanks @gobengo and @benhylau for your advice.

Our last two sites for 2016 and 2018 were built by Richard Caceres, who also deployed them across Dat and IPFS and Zeronet. He created a lightweight CMS for this custom site that allows the full organizing team to add content.

Here’s the main Django application: https://github.com/internetarchive/dwebsummit-site-2

In addition, there’s a private Git repo for deployment, i.e. pushing up to our Dreamhost account.

whanamura commented 5 years ago

We're looking to move in a direction like this: https://ournetworks.ca/

once the new design is done. Until then, need a simple solution to get the basic static pages out.

gobengo commented 5 years ago

If folks were happy with https://github.com/internetarchive/dwebsummit-site-2 last time, it's probably as good an idea as any to just fork it for this year?

IMO django apps is a pretty good way of doing this. I was worried you'd say something like Drupal.

Regardless of CMS, though, I think it's good to checkpoint with deliverables at each of these milestones (so you have leading indicators of the delivery date of the final result and a chance to iterate after each milestone)

benhylau commented 5 years ago

Hi @gobengo, just wanted to respond to what you flagged and our current plan moving forward:

Where/what is the current CMS & Database?

What provider do you want to host dewbcamp.org on?

List of pages required + requirements around any more dynamic functionality (e.g. do people adding content to the CMS need (know how to?) to write raw HTML? Do they need a markdown or WYSIWYG editor or something?

We are drafting the list of pages required now, and need for "WYSIWYG editor" is a main consideration for our decision to roll a CMS-based temporary solution for mid-April. However, we do have intention to move to a static site that is more easily managed by a community, either in June or for next year.

Wireframes of each page (skippable) Final image mockups of each page HTML + CSS + JS (only) implementation of those mockups Only then worry about integrating with quirks of a CMS

Designers are available in June, so what we release in April is minimally designed. We just want to get the information out and link to all the forms for RFP and ticket sales, etc.

By the way, your questions are excellent. June to regroup on this issues seems like a good idea. We have our designers, Lexi and Calvin, available then. People who will actually write content into the site have intention to learn the Markdown/PR-based workflow. (Also exploring something like Prose.io but I always think Prose is a terrible UX. Know of something that actually works?) In June to July I will be on site and can better support this transition, if we decide to transition to a static site then.

musickal commented 5 years ago

Hey folks,

Check out Wagtail, I think it's the best way to go here. It's kinda like the using-Django-admin-as-a-CMS approach on steroids:

https://wagtail.io/ https://github.com/wagtail/wagtail

Since Wagtail IS Django, it should be (relatively) easy to use the old db-- though it'd probably just be easier to re-up everything in whatever format Wagtail wants (it has a great interface for doing this). A week seems like a fair enough estimate for wrangling the old site, but re-upping everything would take maybe a day, less if someone has all the stuff already sitting on their hard drive.

It has lots of tools for generating a static site too. I haven't worked with it in a couple years, but it mostly gets around the design integration overhead/containers-inside-containers problems too. It is still full WYSIWYG though, so it still has that wild-west aspect to it. (So it's more like 2.5x instead of 5x @gobengo)

I think the custom app here was built before Dreamhost had better support for Django. I didn't have too much time to dive into it, but it looks like it'd be easier to do a new Django app for Dreamhost's current feature set and cannibalize stuff from the old site as needed. A lot of that will be redundant though, if you do go with Wagtail (nothing in the models isn't already a feature in Wagtail). Either way I think a "spiritual fork" is a better starting point than a real fork.

The "next step" with this approach would be integrating Wagtail Bakery (static site features) and hooking up all the cool/meshy ways to serve it using whatever that outputs (I haven't worked with it). That way you're adding a feature in Wagtail, not rebuilding in Wordpress and then again in a static site generator (though, to be fair, WP probably has something comparable or even better-- I'd avoid Jekyll at all costs but I've never really jived with it).

TL;DR: Start over with Wagtail. The CMS landscape for Django was really bad in 2015/2016 (rolling your own was a fine solution) but Wagtail in 2019 is pretty great. Right-clicking images on the old site, saving them and re-uploading them will be quicker and easier than wrangling the DB out of the custom CMS or even forking and reskinning. Wagtail also offers better data portability so we wouldn't get the stuff-stuck-in-db problem again.

benhylau commented 5 years ago

Wagtail looks nice :)

I am curious why you want to avoid Jekyll, and whether that applies to static site generation generally, or Jekyll specifically? I have used it in various projects and my only complain would be that the publishing flow takes a while to learn, but that's because a UI for publishing is missing and not due to the concept of static site generation.

musickal commented 5 years ago

Somewhere in-between: Static site generators. I really like the concept of static site generation, but more as a feature than a product unto itself.

The keep-it-simple idea behind them is great, but it breaks down as non-technical people are added to the workflow. WYSIWYG has been a pain for decades now for a reason. People want to log in to a website and use the familiar controls.

So "baking" a complicated Wagtail/Wordpress site into a static site? Great idea. Building that same thing from a bunch of files/folders/plaintext? Not as much. At least not for teams with marketing folks. Even if it looks like a static site from the front, it should still act like an app in the back (insert mullet joke here).

rchrd2 commented 5 years ago

Hello. I was the developer of the previous two versions of the site.

The first year I used a static site generator. This was great for publishing to the dweb, but made the process much difficult for our team.

The second year, I built a CMS using Django and it's built-in admin generator. This worked great, and it enabled our team to collaboratively edit the site, including edit rich text with uploaded images. In order to still publish it to the dweb (IPFS, Dat, ZeroNet), I snapshotted the site using recursive wget to create a static version of the site. This actually worked well. (I can pull up the exact command I used later).

For this next year, I suggested we continue to use the CMS (now forked to dwebsummit-site-2), because the data model has been honed to work well for our purposes (pages, people, videos, and links between those).