[Teammetrics-discuss] GsoC Project Weekly Report 1

[Andreas Tille]

On Tue, May 15, 2012 at 01:37:14PM +0530, Vipin Nair wrote:
> 
> Can avoid JS, but I am not sure what else needs to be done to make it
> "lynx-enabled". Ascii art representation of graphs on detecting
> terminal based browsers should be fun thing to do! :) I'll definitely
> look into this later.

Well, I was obviosely (and intentionally) stretching a bit far when
mentioning lynx.  However, sometimes I'm using w3m (with w3m-img
installed) on a ssh-remote machine and this frequently has some very
reasonable results.  I do not want to make this a "must" criterion but
it is good to keep in mind that there are some use case we should not
exclude just for only "fancy" web layout.  If there are very strong
reasons to break text mode browsers you certainly can convince me to
do so.  However, before we will face such reasons I'm in favour of
KISS (Keep It Simple, Stupid).

> >  1. How to reasonable select 1 team
> >  2. How to reasonable select X teams for comparative display
> >  3. What measures (mailing list activity, commits, closed bugs, uploads)
> >    should be displayed in 1. and 2.)
> >  4. Selecting a certain time span for 1. and 2.
> >  5. How can I ask for a team not yet in the statistics
> >  6. ...
> 
> If we are dynamically rendering the graphs on client side, all these
> can be done in an awesome way. If we a rendering these graphs on
> server side and an image is sent to client side, there cannot be any
> sort of interaction. For example, If I need to add an additional
> metric to an existing graph, Instead of any page reloads, I can redraw
> the graph on the immediately (fetching data from the server
> asynchronously) which is very fast.

I trust you that there are good reasons for client side rendering and as
I said above if non-JS stuff would limit our opportunities drastically
there is no point in refusing to use this.  My point above was that we
first should care for the general logic what we want to present and how
we design the querying interface.  I think once this is done the choice
of the final presentation of the data becomes rather easy because it
would be a natural consequence of this.

If I would try to tackle the task I would try to design those selection
options generating some query to fetch the data and for a beginning just
display the data table instead of a graph.  BTW, we need this plain data
anyway - mind Debian Accessibility team who explicitely asked me for a
textual representation of the data.  Once this is done we can decide about
what toolkit to use (2D / 3D Barplotting whatever).

> If we are rendering the graphs on the server side, instead of doing it
> on demand, it is always better to pre render all the images and just
> send it to the browser when it is requested. But having the graphs pre
> rendered limits what a user can do. Say, if we decide to render a
> particular metric of team for a time span five years, this is fixed
> and the user cannot select the time range, in that way the interface
> becomes less usable.
> 
> On the other hand if we are rendering the images on demand, even with
> basic caching, this would be resource intensive and it will slow down
> the website. Having a fast website is good.
> 
> The best and the cheapest option in terms of server resource
> utilization will be to present data, as is, say in some tabular form
> without any sort of visualization (graphs rendered as images) for non
> javascript environments (works with both javascript disabled browsers
> and terminal browsers) and client side rendering for javascript
> enabled environments.

Sounds reasonable.
 
> The advantages of this approach are:
> 
> 1) Fast
> 
> All we send from the server is text data so it is very fast. For
> example, in the prototype I wrote to support my GSoC application, I
> have provided a static and dynamic example.
> 
>     [1] Static example : http://debmetrics.appspot.com/teammetrics/commitlines/
>     [2] Dynamic example :
> http://debmetrics.appspot.com/dynamic/teammetrics/commitlines/
> 
> If you would have noticed, the dynamic example renders *much* faster
> than loading the image from blends.d.n. In the dynamic example, I am
> generating an image by calling an API that generates JSON data on the
> Google server by parsing a text file on blends.d.n server, in actual
> practice, this will be much faster because I generate the JSON from
> the database in the same server and all the communication overheads
> are removed.
> 
> 2) Efficient
> 
> Since we are only sending text data, it is very bandwidth efficient.
> If we do not render any visualizations on the server, it would be
> consume very less server resources.
> 
> Please to do tell what you think of this idea.

You have given good reasons for client side rendering and as I said I'm
not strictly against it.  The fact that we need to provide textual data
anyway (Debian Accessibility) gives one point more for the method to
render the Graph at the client.  However, as I said we always should try
to be sensible where to put advanced JS stuff and try to avoid it / do
something reasonable if JS is not available.  Just keep in mind that
blind persons are using browsers that could be called even less feature
rich than lynx.  We should not push these users into the dark just for
some funny effects.

> > Following Enrico has proven to be a reasonable thing to do. :-)
> 
> I'll do this soon :)

:-)

Kind regards

       Andreas. 

-- 
http://fam-tille.de