[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Demexp-dev] some thinking on the client: how to improve its usabili
felix . henry
Re: [Demexp-dev] some thinking on the client: how to improve its usability and attract programmers
Tue, 7 Jun 2005 18:46:02 +0200
Internet Messaging Program (IMP) H3 (4.0.2)
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,
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
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,
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
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
-old question on which I have voted
-old question on which I have not voted
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,
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"