[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    KTips dialog replacement (was: Re: )
From:       Randy Kramer <rhkramer () gmail ! com>
Date:       2006-03-16 13:55:19
Message-ID: 200603160855.20712.rhkramer () gmail ! com
[Download RAW message or body]

Just replying to put a title on this email/thread.  

Randy Kramer

On Wednesday 15 March 2006 01:40 pm, Zak Jensen wrote:
> Note: CC'ed the kde-quality and kde-usability mailing lists.
>
> I guess I should first introduce myself, for those who do not know me.
> I am Zak Jensen, a senior at Drexel University, and a long time
> supporter of open source, the KDE project in particular. Some of you
> may know me from kdedevelopers.org (where I have responded to some of
> your blog posts), the kde-usability mailing list, or kde-artists. I
> have been lurking on the kde-devel, kde-core-devel, and kde-quality
> mailing lists for about 2 months now.
>
> About 4 months ago, I proposed a replacement for the KTips dialog: a
> mix between non-intrusive version of clippy, a plasmoid, and the
> present KTips functionality.
>
> http://lists.kde.org/?l=kde-usability&m=112609922114054&w=2
> http://lists.kde.org/?l=kde-usability&m=112611125600245&w=2
> http://lists.kde.org/?l=kde-usability&m=112611417629919&w=2
> http://lists.kde.org/?l=kde-usability&m=112670485931144&w=2
>
> And have also talked about it a bit on the kde-artists forums.
> Unfortunately, the kollaboration forums have been relocated, and I
> cannot find the original post at this time.
>
> In any case, the idea has mutated from being an improvement of KTips
> to a generic "action monitoring" service. The basic idea is to collect
> abstract usage information from users, and analyze it. That analysis
> could be used to target interfaces which should be investigated. The
> information can also be used to pinpoint seldom used interfaces or
> features.
>
> It is important to mention at this point that we are providing an
> abstraction to prevent the perception of our software as malignant
> software. One way that we are doing this is by limiting the type of
> information which the system will accept. We are limiting the input
> information (in future versions) to abstractions like "typing",
> "button click", and "toggle checkbox".
>
> At the moment, we are finding out how the mechanism will work, or if
> it will work at all. Future versions of our software will be built
> with a proper outlook on security and privacy.
>
> My senior design team wishes to integrate with an already existing
> project, and I recommended KDE to them. To those ends, I was wondering
> how interested the community is in the project. We are open to ideas
> for features, feasibility, and recommendations on how to integrate
> with KDE. We are not looking to be incorporated into the project at
> this time. Rather, we require an audience to help us tailor and focus
> our project, and we hope that there will be a few interested projects
> within KDE.
>
> Another portion of our project is defining a generic model for
> graphical user interfaces which can be applied across several
> platforms. If anyone knows of such a model which already exists
> (excepting that defined by a set of libraries) details for that would
> be greatly appreciated.
>
> Attached is the project proposal that we wrote for the class. For best
> viewing, please use Konqueror, the file renders properly in FireFox
> 1.5 as well. We have also created a requirements document, but it is
> too large to send to the mailing list. I can forward it to individuals
> upon request.
>
> Please forward any questions back to this thread or, if I  have posted
> to a particular mailing list in err of its guidelines, to me
> personally.
>
> Thanks,
>
> Zak Jensen
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]