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