Re: [Demexp-dev] some thinking on the client: how to improve its usability and attract programmers

[felix . henry]

Hi David, here are my thoughts about your proposals,


> - programming language: Python vs. OCaml
>
>   Since Thomas has made the RPC mechanism available in Python, it is
>   now conceivable to write some user interface in Python, using
>   e.g. PyGTK. Python is much more known than OCaml. Of course, all
>   current code is in OCaml, so it would need a rewrite in
>   Python. Should we invest time in a Python client?

This could be one approach but if we really want to attract people
I would rather see it the other way around: maybe we can first find some
people ready to invest time in demexp development and ask them what
they would like to use as language.


> - modularity of client.
>
>   The current client is one big binary, with several windows but no
>   real links between those windows. The user might be easily lost in
>   it. I'm thinking at making several binaries, one for each task
>   (vote, browse database, classification). Those graphical programs
>   would be callable from shell scripts, other programming languages,
>   etc.
>
>   Another less extrem approach would be to keep the same single demexp
>   client but add options like --browse or --vote to open directly the
>   requested window, using a demexp URL
>   (demexp://server:port/question/N);
>
>   My main objective: I would like to write the necessary parts so that
>   external developers could reuse them to make a more complex demexp
>   client. For example, I can add options to given informations in
>   textual form that can be parsed by shell scripts (--list-questions,
>   --print-question N).

Here you are mentionning two different issues

1/ The 'single executable' may confuse the user because of the number of
windows and options.

2/ There is an advantage for multiple executables (or the option approach)
because external developper can call the programs in accordance with their
needs.

Concerning 1/, I'm not sure it's that confusing. Too me, at the moment, the
most confusing thing is the impossibility to immediately view the status of
each question:
-old question on which I have voted
-old question on which I have not voted
-new question

Concerning 2/, I agree with your approach, but if it requires a substantial
amount of development time, one should probably check if there are some
developpers out ther ready to use the functionality.


> - usability of client to track changes
>
>   The main issue with the current client is that it is difficult to
>   track changes (new questions, new responses, etc.). In order to
>   improve that, I'm thinking of a two side answer:
>
>   - implement a state (i.e. caching) in the client to store seen
>     questions and their state.
>
>     Implement a timestamp mechanism to track changes (no proposal yet,
>     I'll made a separate email on it);
>
>   - implement "virtual tags" that show unseen questions, unvoted ones,
>     etc.
>
>   Your opinion? Any idea on a way to track changes efficiently?

I'm rather in favor of the client caching approach (mainly because I
do not fully understand the other approaches:-)
Storing this kind of info in the client makes sense at this stage
because most people will always access from the same computer. This
approach does not create additional burden in the server.

> I won't be able to sustain demexp development for two more years
> alone. So we MUST find a way to attract new developers. :)

There are three main possibilities that can be pursued in parallel:
-Finding a large amount of money by "seducing" a rich person/institution
and pay developpers (we have not really tried that yet)
-Promote the project in the OS community (we have already tried
at symposiums but maybe we should dedicate more efforts to this)
-Change the software language to traget a bigger "audience"

     Felix