elisa-developers team mailing list archive

[Peter <peter@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, Jun 20, 2010 at 7:15 PM, Florian Boucault <florian@xxxxxxxxxxxx> wrote:
> 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.

Hi Florian,

I was going to write earlier in the week, but as usual much as I like
Moovida/Elisa I have been busy with other things and other projects.
Sorry for the delay.

Thank you for your long but detailed email. Since no one else has replied,
perhaps everyone agrees with you? ;)

I've replied to some points below.

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

But it was still good :)

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

That's life :(

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

I have to say personally skins are a waste of time. Having
played with rival media centers, many have skins which
completely change the UI and controls. I'd rather have one
great interface than ten mediocre ones.

> * 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].

I contributed a few minor patches - and it was obvious to me from
the mailing lists and forum that almost everyone working on
Moovida was at the company.

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

Worse than I expected.

> 2) The user interface and associated requirements changed often.

Design by committee?

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

I apologise if the next bit seems a bit strong - I don't want this to seem
like a personal attack - I recognise you have far more time invested
in the project than I do, and I really am an outsider. Consider this as
the Devil's advocate if you like ;)

I am surprised to see you seriously suggest another tool kit switch
(to Qt Quick) given as you say the user interface has previously
been rewritten 3 times.

Isn't there a branch of Moovida using Pigment 0.5 already? Wouldn't
that be a worth while thing to pursue? What I don't know (and didn't
get a clear answer from on the official Moovida development list) was
what is the status of Pigment 0.5 - for example will it ever be officially
released?

Clearly you know much more about the internals of the current
(pigment based) UI than I do. Presumably in your judgement a
re-write is better than trying to fix this?

I'm also surprised you think a graphical tool to create and edit GUIs
is needed. I may be thinking like a coder rather than a designer, and
perhaps my ambitions for Moovida/Elisa are not so big, but the core
UI elements appear to all be done (scrollable lists, photo grid, on
screen keyboard, OSD), providing the essential building blocks for
simple plugins etc with a consistent UI.

As I said before, maybe I'm not thinking big, but I would expect
Elisa 1.0.x to continue from Moovia 1.0.x with the UI more of less
unchanged, and maybe switch to Pigment 0.5 for Elisa 1.1.x. There
is a good product here and it can be improved incrementally IMHO.

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

Interesting - and yes, media scanning of TV and films is a big problem
(loosing Windows support would be a big downside though).

However I would have said Moovida 1.0.x needed most work on photos
(e.g. tags and albums) where the alternative plan of using an existing
photo DB makes some sense (e.g. iTunes, DigiKam, F-Sport, what ever).
I had given up on using Moovida for looking at my photo collection.

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

What do you mean by "social tool"? Yes, one could say the TV is
the center of the family room and is a shared social experience.
Do you mean beyond the living room - an online social network?

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

Our TV is hooked up to a computer, and gets used for two main
things - watching TV/videos and Skype video calls to family. The
new Skype Linux API stuff sounds quite exciting for use in media
center software...

> Two major changes are coming.
> The remote as the only input device for media center is not going to
> stand true for long. ...
>
> 3) What Now?
>
> ...
>
> 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?

For any complete rewrite (such as Qt), I would vote no. But I don't
feel I should be voting on this so abstain in favor of the people who
have been coding on Moovida/Elisa directly.

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

To be blunt, I would prefer to see effort put into polishing the Moovida
1.0.x codebase which is already usable. However I recognise that this
is now a volunteer run project and that may not be what people want
to spend their free time doing.

> 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

Regards,

Peter