elisa-developers team mailing list archive

[Florian Boucault <florian@xxxxxxxxxxxx>]

There was a problem with the attachment (it was actually a PostScript
file, not a PDF). Sending again.

Florian

On 20/06/2010 20:15, Florian Boucault 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.
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~elisa-developers
> Post to     : elisa-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elisa-developers
> More help   : https://help.launchpad.net/ListHelp

Attachment: elisa_timeline.pdf
Description: Adobe PDF document