H&D website v2: Difference between revisions

From Hackers & Designers
No edit summary
No edit summary
Line 7: Line 7:
The following is a broad outline for the plans we have to re-build the current frontend website of H&D.
The following is a broad outline for the plans we have to re-build the current frontend website of H&D.


The current setup is composed of a Python program that reads from the WikiMedia instance of H&D (that we use as a CMS of sort), and build up a series of pages:
The [https://github.com/hackersanddesigners/had-py current setup] is composed of a Python program that reads from the WikiMedia instance of H&D (that we use as a CMS of sort), and build up a series of pages:


* a main page showing upcoming and past events
* a main page showing upcoming and past events
Line 13: Line 13:
* an article page, displaying a single wiki article
* an article page, displaying a single wiki article


While this structure holds well, there’s been some evolution in the type of content and the way we want to organize it, which can been seen for example in the ever-growing number of items in the main navigation bar.
While this structure holds well, there’s been some evolution in the type of content and the way we want to organize it. An explicit example of these problems can been seen in the ever-growing number of items forming the main navigation bar.


Moreover, there are still some unclear problems when using some functionalities from MediaWiki (eg when using [https://wiki.hackersanddesigners.nl/index.php?title=Special:Concepts Concepts]), that should either be better documented, or something to re-think.
Moreover, there are still some ongoing difficulties when using some functionalities of MediaWiki (eg when using [https://wiki.hackersanddesigners.nl/index.php?title=Special:Concepts Concepts], or when making articles with particular titles), that should either be better documented, or re-thought of.


== Proposal ==
== Proposal ==
Line 21: Line 21:
Starting from the above situation, here our plan:
Starting from the above situation, here our plan:


* re-write the current Python program (currently using Werkzeug) into a more approachable codebase (eg by converting it to Flask), that can be understood and extended by more people:
* re-write the current Python program (currently using [https://werkzeug.palletsprojects.com/en/1.0.x/ Werkzeug]) into a more approachable codebase (eg by converting it to [https://flask.palletsprojects.com/en/1.1.x/ Flask] — yes, Flask is built on top of Werkzeug), that can be understood and extended by more people; this includes:
** better routing
** improve routing
** split functions and make them composable
** split functions and make them composable
** better error handling when something goes wrong in the wiki
** make it easier to add new features (when necessary)
* re-think how top navigation works, both on wiki level as well as on frontend side
** better error handling when something goes wrong in the wiki (eg it does not bring the frontend website completely down, as it happens now)
* add multi-language support (this should be done on MediaWiki, and then it can be implemented to the frontend)
* re-think how top navigation works, both on wiki level as well as on frontend side (see Concepts problem)
* add a search function to the frontend, to query the wiki-backend
* add multi-language support (this should be done on MediaWiki, and then implemented to the frontend)
* focus on making the website highly accessible for users with different disabilities; keyboard navigation, text-to-speech, english and dutch language, small bandwidth consumption
* focus on making the website highly accessible for users with different disabilities; keyboard navigation, text-to-speech, english and dutch language, small bandwidth consumption
* better integration to the rest of the software that H&D setup and or built in these years: etherpad, livestream, mailing-list, etc
* better integration to the rest of the software that H&D setup and or built in these years: etherpad, livestream, mailing-list, etc
* integrate a bit the ''wiki bits'' of MediaWiki into the frontend, eg last change, article history, has the article being referenced already in another article (within the wiki), etc; this can be put under “transparency”
* do not use any javascript; currently it’s used in the navigation and for adding an image slideshow, alternative solution can be implemented
* do not use any javascript; currently it’s used in the navigation and for adding an image slideshow, alternative solution can be implemented
To discuss:
* add a search function to the frontend, to query the wiki-backend
* integrate more the ''wiki bits'' of MediaWiki into the frontend, eg show article’s last change timestamp, article’s history, if the article you are reading has been referenced in another article (within the wiki), etc; this can be put under “transparency”


== Budget ==
== Budget ==



Revision as of 11:51, 7 November 2020

H&D website v2
Name H&D website v2
Owner André Fincato
Hours [[]]
Budget [[]]
Categories [[]]
Period [[]]

Intro

The following is a broad outline for the plans we have to re-build the current frontend website of H&D.

The current setup is composed of a Python program that reads from the WikiMedia instance of H&D (that we use as a CMS of sort), and build up a series of pages:

  • a main page showing upcoming and past events
  • a section page, listing pages under a specific Category
  • an article page, displaying a single wiki article

While this structure holds well, there’s been some evolution in the type of content and the way we want to organize it. An explicit example of these problems can been seen in the ever-growing number of items forming the main navigation bar.

Moreover, there are still some ongoing difficulties when using some functionalities of MediaWiki (eg when using Concepts, or when making articles with particular titles), that should either be better documented, or re-thought of.

Proposal

Starting from the above situation, here our plan:

  • re-write the current Python program (currently using Werkzeug) into a more approachable codebase (eg by converting it to Flask — yes, Flask is built on top of Werkzeug), that can be understood and extended by more people; this includes:
    • improve routing
    • split functions and make them composable
    • make it easier to add new features (when necessary)
    • better error handling when something goes wrong in the wiki (eg it does not bring the frontend website completely down, as it happens now)
  • re-think how top navigation works, both on wiki level as well as on frontend side (see Concepts problem)
  • add multi-language support (this should be done on MediaWiki, and then implemented to the frontend)
  • focus on making the website highly accessible for users with different disabilities; keyboard navigation, text-to-speech, english and dutch language, small bandwidth consumption
  • better integration to the rest of the software that H&D setup and or built in these years: etherpad, livestream, mailing-list, etc
  • do not use any javascript; currently it’s used in the navigation and for adding an image slideshow, alternative solution can be implemented

To discuss:

  • add a search function to the frontend, to query the wiki-backend
  • integrate more the wiki bits of MediaWiki into the frontend, eg show article’s last change timestamp, article’s history, if the article you are reading has been referenced in another article (within the wiki), etc; this can be put under “transparency”

Budget