_[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](https://wiki.gnome.org/Apps/Dia).


## Requirements

### Indymedia past

For the desktop format web front end we are choosing to strictly hold true to
the format of the original indymedia community.
We will diverge a little for mobile devices.

Core functionality that we aim to replicate:

- Three column layout (at least for desktop)
  - Centre: Feature articles
  - Left: Links
  - Right: Newswire
- IMC membership
- Curation
  - "Moderation" tools
  - Flagging
- Rollback
  - Removal of a data source (feed) optionally removes any existing data from
    that source
- ...

Ref: [UK Indymedia](https://indymedia.org.uk)
Ref: [Oxford IMC](https://www.indymedia.org.uk/en/regions/oxford/)

### Indymedia present

Helping work toward a 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.

### 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.

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