[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: David MENTRE
Subject: Re: [Demexp-dev] some thinking on the client: how to improve its usability and attract programmers
Date: Tue, 07 Jun 2005 19:47:24 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

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.

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

reply via email to

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