elisa-developers team mailing list archive

[Florian Boucault <florian@xxxxxxxxxxxx>]

DISCLAIMER: this mail is a very long read, make sure you have popcorn.
DISCLAIMER 2: what is said here is my own view of things and I would
appreciate any factual corrections as well as opinions.


1) Why Elisa Media Center?

* Finishing off Moovida's UI as it was initially designed

Moovida as a product was never completed. Moovida was called 1.0 for
pure marketing reasons even though not all the basic features that were
designed got implemented.

* Cleaning up Moovida's code mess

Moovida internally has a lot of clean parts and also many dirty ones.
The invisible hand of pressure never allowed to put in motion the
cleaning process as it was planned.

* Going beyond Moovida

A number of very innovative features are still lacking in media centres.
Working with a solid UI template and a strong codebase will make the
process of implementing them much easier and faster.
Also, while sticking with a single ergonomical concept, skins with
different color schemes, layouts, animations, will be developed.

* Having fun

Making Elisa equals writing clean, lean user interfaces while learning
and building new cool technologies. It's definitely an exciting part of
the equation that drives us all.

* Being part of a community

Moovida had a very talented team that worked hard and learnt a lot while
writing it. It was a very enjoyable experience that is worth
replicating. Done right, we will gather amazing new members and create a
vibrant community around Elisa's ideas.

* And of course, meeting up in cool cities like Barcelona...


2) How-to Elisa?

a) Why did Moovida fail?

First of all, did Moovida fail? Yes and no.

* From a pure number of users perspective, the 10000 regular users
(roughly) did not meet the expectations. The activity in the forums and
mailing list reflect a community of proactive users of around 20 people.

* From a developer community perspective, 1 core developer existed
outside of the company and 1 other contributed patches on a regular
basis. Around 8 people outside of the core team created plugins for a
total of around 40 plugins, mostly Internet content related [1].

* From a product perspective, Moovida was not ready for mass
distribution. Statistics speak for themselves with 10 critical bugs and
100 high importance bugs across the board. Particularly crowded areas are:
- User Experience and 'Visual' with over 50 high importance bugs [2, 3]
- Media scanning with over 15 critical or high importance bugs [4]
- Windows version with 35 critical or high importance bugs related to
installation, startup (special mention for the 80 untriaged bug reports
about failing startups on windows [5]), playback and crashes (search for
[win32] on bugs.launchpad.net/moovida)

* From a technological perspective, Moovida created a framework for
cross-platform media based applications with animated user interfaces
that was never finished. Pigment 0.5 [6, 7], the PAF animation framework
[8], the 2D GUI framework based on top [9], the RDF based media scanner
and the declarative language for content plugin writing are as many
exciting technologies that never saw the light of the day.

* From a software development perspective, features implementation and
QA became very smooth thanks but not limited to:
 - separated branches for new features and bug fixes with code and
functional reviews required before merging
 - clockwork monthly releases
 - weekly bug fixing day [10]
 - efficient bug triaging with a sensible partition of the bugs space

However the state of certain parts of the code base did not always allow
painless insertion of new features or bug fixing. The following
fundamental code-only issues were particular annoyances:
- hacked up 2D Python scenegraph (fixed with Pigment 0.5)
- cumbersome list controllers and resource providers architecture to
build menu hierarchies and media content lists quickly
- media scanner spaghetti code
- surreal database schema
- broken cancellation of asynchronous tasks (artwork downloads, etc.)
- lack of a standard, robust http client
- inconsistent management of path encoding

And on the less fundamental (= easily fixable by rewriting) side:
- theming spaghetti code (fixed with lp:~fboucault/elisa/new_theme)
- player spaghetti code
- leaky browser (fixed with lp:~fboucault/elisa/browser_ng)
- search UI spaghetti code
- recategorisation UI spaghetti code


Let's restate. Did Moovida fail? Yes.
Why? Users' expectations were not met feature wise and stability wise.
Why? An attentive observer will see a combination of 2 patterns emerge.

Let's look at Elisa's development timeline [11] that draws a very rough
summary of what happened over the years. First obvious observation:
Elisa was partly rewritten numerous times. A more attentive observer
will note that the parts that were rewritten over and over were: the
user interface (3 times), the user interface toolkit (3 times), the
content management infrastructure (twice). And as a bonus that does not
appear on that timeline, the local file indexer (aka. media scanner) was
written on 3 different occasions as well.
The same attentive observer will ask himself: where did my 250
man/months manpower go? After cross referencing that timeline with
commit logs she comes up with the following very rough numbers:
- 35% UI toolkit writing
- 20% UI writing
- 10% Media scanner

We can safely say that no more than 35% of the time (what's left from
the above list) were actually dedicated to making a media center, let
alone meeting end users expectations or innovating. In reality an
important part of the remaining 35% were dedicated to writing general
architecture, content plugins, fixing bugs, triaging bugs, testing,
releasing, etc.

So, what are the 2 patterns that emerge from that?
1) A considerable amount of time was spent in the base libraries rather
than focusing on the core business of a media center.
2) The user interface and associated requirements changed often.

Pattern 1) came from a NIH syndrom as well as a lack of available
technologies suitable for the job at the time.
Pattern 2) had its roots in a lack of understanding of how user
experience design works and more than anything else a dear lack of long
term, thought through, written up, vision.


b) How to avoid the damaging patterns?

*User Interface Technology*

We need a solid, complete and sustainable solution for the graphical
user interface creation (designer) and delivery (developer).

The fact that we were building our own technology with very few
resources and no prospect of getting more. That led to a lack of
available features (not complete) and a lack of long term sustainability.

The fact that we had no visual tool to build the user interface made us
go through the typical back and forth between designer and developer.
That can be largely avoided. I would like to have the designer able to
put together the interface using the exact same tool as the developer.
That tool has to be no harder than Flash and must allow visualising at
all times what the interface looks like and how it behaves. A side
effect of using such a tool is that it will allow for much greater
contribution on the UI level in general and also on the skinning level.

Today, the best open source solution that satisfies all these criteria
is Qt Quick [12]. It is a set of Qt technologies focused on creating 2D
canvas-based, highly animated, pixel perfect, user interfaces. It
features a user interface description language (QML) natively integrated
with JavaScript and a GUI to visualise and edit the user interface
called Qt Creator [13]. It is completely cross-platform (Windows,
MacOS/X, Linux) and also targets smartphones. It has been developed by
Nokia for over a year and they are heavily investing on it. It has a
very shallow learning curve. It is in beta right now and the first
stable release should happen anytime now.

Why not Clutter or Pigment 0.5 or toolkit X/Y/Z?
The ideal UI toolkit should feature a declarative user interface
description language in order to have a graphical tool to create and
edit GUIs. That IDL should support natively:
- animations
- the creation of reusable components
- variable binding
- signal programming
- a scripting language to write more complex UI logic

The idea candidate should allow to write most of the product only using
that language.
Note: there are some other more obvious feature requirements that the
toolkit should satisfy: use of hardware acceleration, media framework
integration, support for scalable and pixel-perfect UIs and more.

Drawbacks of Qt Quick: the major issue today is the very limited support
of 3D even though the developers are working towards it.


*Media Scanning*

There are existing solutions which most of the time only lack the
ability to recognise films and TV series. So far the most promising one
is Tracker [14]. It is quite fast and reliable, based on RDF and has a
good support from a number of companies.

Drawbacks: it is not readily ported to other platforms than Linux. I am
sure that would be doable and in the meantime it is certainly possible
to integrate with similar technologies built-in the other operating systems.


*Long Term Vision*

As of today there is none. The challenge is to come up with one through
thinking, discussion, prototypes, debates. That will take time and
effort. The agreed upon basis we are starting from is the following:

- The user interface and interaction is everything; simplicity &
usability are keys.
- The target group is anyone/any age with content and a TV.
- Defaults matter.
- Elegance matters.
- It is more than just a piece of software, it's a social tool.
- It is also more than a playback machine, it has features that make it
that social tool both in real life in your living room and over the
Internet.

Also one might find very useful to browse through the collective list of
all the feature requests and ideas gathered over the years:

https://bugs.launchpad.net/moovida/+bugs?field.tag=feature-request
https://blueprints.launchpad.net/moovida
https://wiki.elisa-media-center.org/FeaturesIdeas

I do not know of a set process whereby we would come up with the right
questions and answers. If anyone does, please let me know. In the
meantime I will start with sharing some general thoughts.

I do believe that a media center's goal is not only media collecting and
playback. It is a tool put on the TV in the living room that people
should be able to use whenever they are around it for all kinds of
purposes. In the morning before going to work they might want to check
the weather forecast or read the news. They might want to connect with
friends and family passing video calls. There are many use cases apart
from media related things. Even on that front we are nowhere near the
end of how it could be done better. We talked about personal collections
and media exploration. These are my favourites but I am sure there are
many more to come.

Two major changes are coming.
The remote as the only input device for media center is not going to
stand true for long. Other input devices will come along, maybe touch
based, maybe gesture based, I don't know.
More importantly, and we talked about that before, the way to deliver
the media center: inside the TV, or in a separate set-top box, or on a
smartphone or on the casual laptop.
Two factors are critical here:
- in the case of separate devices: the ease of connecting such device to
the TV (I would bet on wireless HDMI)
- *where* the user's content is located. Is it going to be on a desktop
computer at home? On a laptop? On the Internet? On a phone?

These call for a lot of thinking. However, in order to be future proof I
do believe that our technological choices should allow us to run everywhere.


3) What Now?

That's a lot of talking and very little action one might argue.
Here is what we have as of now:
- people: https://launchpad.net/~elisa-developers
- a launchpad project page: https://launchpad.net/elisa
- a wiki: https://wiki.elisa-media-center.org/
- an IRC channel: #elisa@freenode
- a mailing list: elisa-developers@xxxxxxxxxxxxxxxxxxx
- a prototype based on Qt and Tracker:
https://code.launchpad.net/~fboucault/+junk/elisa_qt

Yes, you heard right! For the last 2 weeks, Michal and I supported by
Ahmed, put together a quick and clean prototype of what Moovida's UI
built with Qt and Tracker would look like. The idea behind it is first
to prove that it is indeed possible to build at least the same
featureset but in a much shorter timeframe and second, to create a clean
code base we can work from on the longer term.
The prototype so far includes:
- scanning of mass storage devices for content
- a main menu
- music albums, artists, tracks
- photos sorted by date
- unclassified videos
- audio and video playback
- ... and many other small goodies

It looks like that on my desktop: [15, 16]
... and like that on a N900: [17]
... and like that on a Beagle board: [18]

(disclaimer: the screencasts are a bit old).

Some would say: "promising.", some would say: "OMG! AWESOME!!". The
least that can be said is that the code is small and simple to work with.


4) Next Steps

I propose to follow the following steps:

Step 1: a quick round table would be useful to see if everyone is with
us about the choice of Qt and Tracker; yes or no?

Step 2: finishing up the replication of Moovida's features in what today
is called Elisa Qt. A list of tasks is available in the code base under
the name TASKS. It should be moved to the wiki there: [19].

Step 3: communication with the rest of the world; apart from the obvious
website and blog articles and such there is also a list of the most
active people in Moovida, people who would surely be interested in
knowing about Elisa's existence.

And as a background task, discussion and finding of a long term vision
as explained earlier.


Thank you for reading this far.

All comments, suggestions and remarks are welcome and appreciated!

Florian


[1] https://launchpad.net/moovida-universe
[2] https://bugs.launchpad.net/moovida/+bugs?field.tag=user-experience
[3] https://bugs.launchpad.net/moovida/+bugs?field.tag=visual
[4] https://bugs.launchpad.net/moovida/+bugs?field.tag=media-scanner
[5] https://bugs.launchpad.net/moovida/+bugs?field.tag=startup
[6] https://code.fluendo.com/pigment/trac/wiki/Plans_for_0.5
[7] https://guij.emont.org/blog/2008/03/11/future-of-pigment/
[8] http://live.gnome.org/PAF
[9]
http://bazaar.launchpad.net/~moovida-developers/moovida/relook/files/head:/elisa-plugins/elisa/plugins/pigment/widgets/
[10] https://launchpad.net/moovida/+milestone/bug-fixing-day
[11] attached document 'elisa_timeline.pdf'
[12] http://blog.qt.nokia.com/2010/02/15/meet-qt-quick/
[13] http://qt.nokia.com/products/developer-tools/
[14] http://live.gnome.org/Tracker/
[15] http://people.canonical.com/~kaleo/elisa/elisa_qt.png
[16] http://people.canonical.com/~kaleo/elisa/latest.ogv
[17] http://people.canonical.com/~kaleo/elisa/elisa_qt_nokia_n900.ogv
[18] http://people.canonical.com/~kaleo/elisa/elisa_qt_beagle_board_720p.ogv
[19] https://wiki.elisa-media-center.org/TaskList

Attachment: elisa_timeline.pdf
Description: Adobe PDF document