H&D website v2: Difference between revisions
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
|Owner=André Fincato | |Owner=André Fincato | ||
}} | }} | ||
== Intro == | == Intro == | ||
The following is a broad outline for the plans we have to re-build the current | The following is a broad outline for the plans we have to re-build the current website of H&D. | ||
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: | 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: | ||
Line 14: | Line 15: | ||
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. There are also 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. | 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. There are also 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. | ||
Moreover, the current set-up doesn't take into consideration several different points of access: the website is not screen-reader-friendly, takes time to load (as pages are rendered when requested), and it only supports the english language. There is an imminent need to address these issues. | |||
== Proposal == | == Proposal == | ||
Taking into account the above points, we propose a project that is in two parts: (1) general updates for accessibility and (2) internationalization.These are both inter-connected but because of the way budget has been allocated and shifted in the last two years to different tasks, this project has to be dealt with in 2 separate sections. (see section spreadsheet tetris) | |||
=== (1) General Updates for Accessibility === | |||
This section details the task of completely re-writing the website's front- and back-end in order to improve reader experience, create a more points of access, have less server-intensive and ecologically heavy rendering processes, and introduce a new stylesheet and navigation logic. | |||
To do: | |||
* 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: | * 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: | ||
** improve routing | ** improve routing | ||
** split functions and make them composable | ** split functions and make them composable | ||
** make it easier to add new features (when necessary) | ** make it easier to add new features (when necessary) | ||
** server side rendering: HTML pages are rendered when they are created or edited in the wiki jnstead of on every request | |||
** better error handling when something goes wrong in the wiki (eg it does not bring the frontend website completely down, as it happens now) | ** 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) | * Design and layout | ||
** add a search function to the frontend, to query the wiki-backend | |||
** re-think how top navigation works, both on wiki level as well as on frontend side (see Concepts problem) | |||
** new design and stylesheet | |||
* Creating and Improving Points of Access | |||
** Impletement keyboard navigation (tab-indexing) | |||
** Comply with ARIA standards for screen-reader accessibility (aria-labels / aria-roles) | |||
** remove unnecessary javascript; (navigation and for adding an image slideshow) | |||
** Do a web audit with a professional (Eric?) | |||
* GDPR & Web Analytics | |||
** We use web anaylitcis but oour readers dot know => this is illegal | |||
To discuss (not yet budgeted for): | |||
* integrate more the ''wiki bits'' (metadata) 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” | |||
* explore a new solution for hosting/servinng audio and video | |||
* better integration to the rest of the software that H&D setup and or built in these years: etherpad, livestream, mailing-list, etc | |||
* Install ethercalc and migrate database from karls.computer | |||
=== (2) Internationalzation === | |||
* add multi-language support (this should be done on MediaWiki, and then implemented to the frontend) | * add multi-language support (this should be done on MediaWiki, and then implemented to the frontend) | ||
* | == Timeline == | ||
* November 2020: drafted the project and wiki and started on the backend (see article history) | |||
* May 2021: work halted | |||
* February 2022: re-wrote project plan to account for 2022 language and translation budget | |||
* March 2022: frontend work starts | |||
* May 2022: Deadline | |||
== Budget / Spreadsheet Tetris == | |||
In 2021, Initially, the project was budgeted 6.700,- under the theme of "digital accessibility". Not much of this work was done and no hours were invoiced for it. Although, notably, 800 euros were spent from the digital accessibility budget (by karl and andré) to cofinance research on standard web-accessibility practices for the obfuscation workshop platframe. What remains is 5.900,- ([https://docs.google.com/spreadsheets/d/1ZPdV7iJmUB2-mmyMs6RVMVCQXiQlURzLLi1w7nbjHvA/edit#gid=1416820654 see row 17]). | |||
In 2022, there has been a budget of 5.200,- allocated for [https://docs.google.com/spreadsheets/d/105NN0pZvKtiAOehAf_WsI6kv-osyij60/edit#gid=1408357688 "Translation"]. This project should only have access to part of this budget, as a large part of it would go the actual work of translation of wiki pages, open calls, application texts, newsletters, etc... This work of translation is not accounted for in this project and should be given a dedicated project page, although they both feed from the same budget. | |||
Conclusively, the project's two parts, accessibility improvements and internationalitzation, are budgeted separately: | |||
budget table | |||
Tracking hours will happen on this spreadsheet: |
Revision as of 14:14, 11 February 2022
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 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. There are also 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.
Moreover, the current set-up doesn't take into consideration several different points of access: the website is not screen-reader-friendly, takes time to load (as pages are rendered when requested), and it only supports the english language. There is an imminent need to address these issues.
Proposal
Taking into account the above points, we propose a project that is in two parts: (1) general updates for accessibility and (2) internationalization.These are both inter-connected but because of the way budget has been allocated and shifted in the last two years to different tasks, this project has to be dealt with in 2 separate sections. (see section spreadsheet tetris)
(1) General Updates for Accessibility
This section details the task of completely re-writing the website's front- and back-end in order to improve reader experience, create a more points of access, have less server-intensive and ecologically heavy rendering processes, and introduce a new stylesheet and navigation logic.
To do:
- 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)
- server side rendering: HTML pages are rendered when they are created or edited in the wiki jnstead of on every request
- better error handling when something goes wrong in the wiki (eg it does not bring the frontend website completely down, as it happens now)
- Design and layout
- add a search function to the frontend, to query the wiki-backend
- re-think how top navigation works, both on wiki level as well as on frontend side (see Concepts problem)
- new design and stylesheet
- Creating and Improving Points of Access
- Impletement keyboard navigation (tab-indexing)
- Comply with ARIA standards for screen-reader accessibility (aria-labels / aria-roles)
- remove unnecessary javascript; (navigation and for adding an image slideshow)
- Do a web audit with a professional (Eric?)
- GDPR & Web Analytics
- We use web anaylitcis but oour readers dot know => this is illegal
To discuss (not yet budgeted for):
- integrate more the wiki bits (metadata) 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”
- explore a new solution for hosting/servinng audio and video
- better integration to the rest of the software that H&D setup and or built in these years: etherpad, livestream, mailing-list, etc
- Install ethercalc and migrate database from karls.computer
(2) Internationalzation
- add multi-language support (this should be done on MediaWiki, and then implemented to the frontend)
Timeline
- November 2020: drafted the project and wiki and started on the backend (see article history)
- May 2021: work halted
- February 2022: re-wrote project plan to account for 2022 language and translation budget
- March 2022: frontend work starts
- May 2022: Deadline
Budget / Spreadsheet Tetris
In 2021, Initially, the project was budgeted 6.700,- under the theme of "digital accessibility". Not much of this work was done and no hours were invoiced for it. Although, notably, 800 euros were spent from the digital accessibility budget (by karl and andré) to cofinance research on standard web-accessibility practices for the obfuscation workshop platframe. What remains is 5.900,- (see row 17).
In 2022, there has been a budget of 5.200,- allocated for "Translation". This project should only have access to part of this budget, as a large part of it would go the actual work of translation of wiki pages, open calls, application texts, newsletters, etc... This work of translation is not accounted for in this project and should be given a dedicated project page, although they both feed from the same budget.
Conclusively, the project's two parts, accessibility improvements and internationalitzation, are budgeted separately:
budget table
Tracking hours will happen on this spreadsheet: