indymedia-reboot/design-overview
Admin ed9701c2b4 Update 'design-overview/README.md' 2023-03-31 19:10:04 +00:00
..
README.md Update 'design-overview/README.md' 2023-03-31 19:10:04 +00:00
indymedia_design-overview.dia Add beginnings of a design plan 2023-03-31 12:18:33 +04:00
indymedia_design-overview.pdf Add beginnings of a design plan 2023-03-31 12:18:33 +04:00

README.md

[N.B. This text is incomplete, contains errors and/or inaccuracies - question and seek clarification, rather than dismiss.]

Design Overview

We need a somewhat high level view of what we are intending to build. It should include aspects of the low level details but we are not aiming at your corporate-style UML diagrams - we want something that has a reasonable chance of holding true to what gets created.

Diagram

As it stands, the diagram is intended to get the ball rolling. If you want to edit or view the original diagram, see Dia.

Requirements

Indymedia past

For the desktop format web front end we are choosing to hold true to the format of the original indymedia community. We will build on there early inplemtation for for mobile devices.

Core functionality that we aim to replicate:

  • Three column layout for desktop, this becomes a simple singal swip interface (no JS menue) layout for mobile
    • Centre: Feature articles
    • Left: Links
    • Right: Newswire
  • IMC membership
  • Curation
    • "Moderation" tools
    • Flagging
  • Rollback
    • removing data to a date
      that source
  • ...

Ref: UK Indymedia Ref: Oxford IMC

Indymedia present

Helping work toward a #KISS semantic web.

  • Tags/ metadata as a first-class citizen
    • It should be trivial to embelish existing data with more
    • Searching/filtering should be fast
  • ...

Indymedia future

This comes later. And is not solely for us to define, we reboot the existing working groups

Graceful degradation

We aim to design for accessibility first. All pages should function and read well - at least for their essential uses - without Javascript (JS) or even CSS.

While JS will be utilised, it must only be done so to enhance - it must never be the only way to achieve something. yes.

[Can anyone think of a case where we can't uphold this? - Open an issue]