Oralsite Future

From ActiveArchives
Jump to: navigation, search

Ownership (?) + editing

  • finer grained permissions: for instance a user be allowed to edit only specific parts of oralsite

permission to edit? Or just make revert more accessible?

  • Question of privacy. Shared spaces, private spaces.

permission to view. or Private installations and then the possibility to push/pull between repositories.

  • Tags: beeing able to overview/retrieve material from different pages. If you start tagging, how to protect the studio environment (because tags are global at the moment)

allowing or not to index pages (like robots.txt)? Private indexes

  • history/conflict/privacy/merging/branches/etc.

modèle en deux étapes. Base de données + git. Style etherpad: star revision = commit. Ou alors regarder du côté HTML5 server side persistence ? markdown: une étape de plus à parser. Pour Sarma, ils ont déjà investi dans le markdown. déjà écrit des plugins python-markdown pour rdfa etc.

passer tout en javascript, et utiliser phantom.js / ghost.py pour sniffer. où à plusieurs où LOCK

backbone.js -> à étudier. Seul problème: éditer les sous-sections.

implémenter des rss pour voir ce qu'il se passe sur le site?

tester sur des uses-cases (par example les filres markdown existants)

faciliter l'association de resources et d'annotations

Contents

Interface

Layout tools

  • grid layout: http://www.researchcatalogue.net/view/18701/18702/0/323
  • percentages: snapping. Tools to align and distribute (like in inkscape). Enabling Disabling the grid.
  • Smart snapping. Anchors (positioning relative to other boxes).
  • Visual feedback of what is going on in terms of positioning.
  • utiliser less css pour les modes

interface plus épurée, à la hotglue. structure non basée sur les headers.

bouton pour ranger les boites/spring layout. Pouvoir remettre les choses à leur place ensuite (mode) ou non (action). Plutôt action?

eg. http://rouges-gorges-et-cosaques.net/

Format support

  • compatibility: warning or improving support for other browsers.
 * offering several audio and video formats (ogg + mp4 + mp3 + webm etc.
 * better encoding and serving of media files
 * flash support
  • embeds: youtube and vimeo support back

http://wam.inrialpes.fr/timesheets/ https://bitbucket.org/tadp/timesheets/wiki/Home http://mediaelementjs.com/

test suite.

  • bug: TOC click doesn't necesserally scroll to the right box.
  • image gallery. related to offering different audio/video format.
  • manual not complete.

Ludivine:

  • advices, working together on pages, taking the most of what is already there.
  • single collages
  • archive
  • creative possibilities of annotation. Poems

Near future

  • alert about missing disk. Look at caching if it can be less space eating. Choosing by one-self if it needs to be cached or not. Garbage collecting: removing from cache unsed resources. filter that doesn't cache resources from the same server.
  • empty section header code bug
  • example of transparent boxes use
  • clicking timecodes in a box doesn't jumps in the audio file/video file
  • visualizing more easily the connexion between the resources and the annotations
  • importing/exporting of audacity broken
  • automatic playing
  • windows shortcuts
  • install bugtracker/number versions
  • * * * *

a pipe that asks what do you give me/what can I accept. http://html5doctor.com/small-hr-element/

  • * * * * *
  • upload + transcode videos and stuff
  • backup: raspberry pi
  • * * * * *
  • aacore -> aasniffer + aabrowser

chantiers

migration

Devis

modèle en deux étapes. Base de données + git. Style etherpad: star revision = commit. Ou alors regarder du côté HTML5 server side persistence ? backbone.js -> à étudier. Seul problème: éditer les sous-sections. implémenter des rss pour voir ce qu'il se passe sur le site? faciliter l'association de resources et d'annotations

  • tester sur des uses-cases (par example les filtres markdown existants)

Interface

  • bug: TOC click doesn't necesserally scroll to the right box.

Near future

  • alert about missing disk. Look at caching if it can be less space eating. Choosing by one-self if it needs to be cached or not. Garbage collecting: removing from cache unsed resources. filter that doesn't cache resources from the same server.
  • clicking timecodes in a box doesn't jumps in the audio file/video file
  • visualizing more easily the connexion between the resources and the annotations
  • importing/exporting of audacity broken
  • automatic playing
  • windows shortcuts

Architecture

In the current version the current version of oralsite, every page is one single text (source code) and annotations boxes are determined by convention based on this document structure (level 1 header). While this idea is beautiful because it makes the page entirely writable by hand, but also easily backable and transportable, it also introduces a lot of complexity as soon as content gets manipulated visually.

For instance, when you moves an annotation box, the source code of the page is litterally altered by the system. But because the language it as to write (markdown) is more suited to people than to machines it asks for a lot of conversions and, on top of that, a lot of bookkeeping (eg. section number) which makes hard to avoid many bugs we had.

We want to keep the wiki-like syntax, because once you get used to it it allows to write and structure your documents in one single act. But to also make it easier to layout document, we would like to switch back to an architecture where annotations are distinct objects for the system, and though are much more easilly manipulable for it. Data would be saved server-side and rendering done in the browser, making bookkeeping easier and the application more reactive and relieving the server from much computation.


API

  • modelizing 2 days
  • Versioning 3 days

Annotations

  • manipulation / edition 2 days
  • markdown syntax to javascript 2 days

Tags, Indexation

  • adapting the indexing code to the new architecture 1 day
  • filters 2 days

User permissions

  • authentication system 1/2 day
  • viewing/editing/reverting/indexing permissions 1 day

Interface and layout tools

We would like to keep Oralsite close to what it is right know, but maybe a little bit more playful. We are inspired by the interface of hotglue http://hotglue.me/demo/ and it's contextual-menus (accessible by (signle/double) cliking on the canvas and on objects. We like the fact that pages are by default totally blank and that functionnalities offered are contextual and don't clutter the interface.

  • hotglue like interface 2 days
  • Miniature navigation map. 1/2 day
  • grid and snapping helpers 1/2 day
  • CSS/templates 2 days
  • annotation distribution actions: spring layout, cascade layout... 1 day

Media support

  • flash fallback for unsupported formats 1 day
  • youtube and vimeo support 2 day
  • playing annotations ?
  • playlists ?

Miscellaneous

  • migrating the old website 2 days
  • deployement 1 day

options

  • better encoding and serving of media files 1 day
  • documentation: 1 day

repenser radicalement le sniffing si on part sur backbone? link to rdf resource?

interface: no more boutons: drag out shapes


Markdown Libraries

If we go for javascript, we need to reimplement the markdown extensions we've been develloping in python:

  • mdx_timcodes
  • mdx_semanticdata
  • mdx_semanticwikilinks
  • mdx_del_ins (low priority)
  • mdx_cite (low priority)
  • mdx_outline (may be unnecessary)

and python-markdown extensions:

  • attr_list
  • headerid
  • footnotes (?)
  • def_list (low priority)
  • meta (?)

To look at and compare:

Marked

https://github.com/chjj/marked

Pros

  • Advertised as very fast, like 6/7 times faster than markdown-js
  • Exposes the internal lexer
  • coding-style very readable

Cons

  • no plugin api

Markdown-js

https://github.com/evilstreak/markdown-js

What links here

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox