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

[David MENTRE]

Hi Félix,

address@hidden writes:

> 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.

Yes, it would be wiser. Just show me an external demexp developer. ;)

> 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

Yes. Everybody is telling me that. :) 

> 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.

Sure. It is a kind of chicken & egg issue: develop modules and
functionalities to attract developers to develop new modules and
functionalities. I need to bootstrap the process, however I don't know
how. I'm just trying to make a guess.

>> - 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:-)

In fact, I need both options to implement full change track as perceived
by user. :) The caching is used as a back-end, to follow changes. The
"virtual tags" can be used to present information to the user. I've been
suggested to use bold/italic on tags, similar to email readers, as a way
to see new/unvoted questions.

> 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.

Yes, I try to add most functionalities in the client, i.e. the server
does hardly nothing, except providing raw data. It is probably more
complicated if someone wants to code a new client but is probably more
scalable (time will tell).

Many thanks for the feedback.

Yours,
d.
-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A