ed9701c2b4 | ||
---|---|---|
.. | ||
README.md | ||
indymedia_design-overview.dia | ||
indymedia_design-overview.pdf |
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
- removing data to a date
- ...
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]