[Top][All Lists]

[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

From: felix . henry
Subject: Re: [Demexp-dev] some thinking on the client: how to improve its usability and attract programmers
Date: Tue, 7 Jun 2005 18:46:02 +0200
User-agent: 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,
  --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

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,

  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"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]