28 Mar
2011
28 Mar
'11
8:45 p.m.
On Sat, Mar 26, 2011 at 4:20 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2011-03-25 16:02, Ammar Yasir a écrit :
I had a doubt (it might be silly but I thought I should ask). One important
feature of such a data visualization system is that it should not create
confusion or represent something that the data is not. Consider the movie
database example, when a user sees a plot of ratings vs year / genre vs
lanuage, a lot of data points will overlap. So a lot of data will be hidden
from the user at the first sight. What will a user make out of it? I know we
handle such conditions by providing all the data instances when he clicks on
the point but a user might not go that far. If he is not able to understand
the initial plot he might not continue further ( like not zoom in/click data
point). I am just a little concerned about the usability part and not the
functionality.
--
Thanks for the comments. I'll try to include
all possibilities (using
existing pChart or SVG) in my proposal. One more question, it was
required
on our part to submit a patch before we submit
our proposal.
I submitted a patch for mass table prefix change (
http://sourceforge.net/tracker/?func=detail&aid=3220779&group_id=23…
).
Its for one of the 'Tasks for Junior
developers' and its working fine
(nijel
verified that) but not accepted yet, so will it
count or I'll have to do
something more before I could submit?
I changed the resolution to "accepted" and you don't need to send
another patch before sending your project proposal.
Thanks Marc Delisle
http://infomarc.info
29 Mar
29 Mar
8:31 a.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
Ammar Yasir a écrit :
Thanks
I had a doubt (it might be silly but I thought I should ask). One
important feature of such a data visualization system is that it should
not create confusion or represent something that the data is not.
Consider the movie database example, when a user sees a plot of ratings
vs year / genre vs lanuage, a lot of data points will overlap. So a
lot of data will be hidden from the user at the first sight. What will a
user make out of it? I know we handle such conditions by providing all
the data instances when he clicks on the point but a user might not go
that far. If he is not able to understand the initial plot he might not
continue further ( like not zoom in/click data point). I am just a
little concerned about the usability part and not the functionality.
I don't think that the plot contains all that. In the example I have
seen, the X axis contained "year of release" and the Y axis was for
"popularity level from 1 to 9".
There were buttons at the bottom to select genre but this was not part
of the data points.
--
Marc Delisle
http://infomarc.info
8:56 a.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
On Tue, Mar 29, 2011 at 5:01 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Ammar Yasir a écrit :
popularity. Those movie points will overlap on the 2D space, what then?
Thanks
I had a doubt (it might be silly but I thought I should ask). One
important feature of such a data visualization system is that it should
not create confusion or represent something that the data is not.
Consider the movie database example, when a user sees a plot of ratings
vs year / genre vs lanuage, a lot of data points will overlap. So a
lot of data will be hidden from the user at the first sight. What will a
user make out of it? I know we handle such conditions by providing all
the data instances when he clicks on the point but a user might not go
that far. If he is not able to understand the initial plot he might not
continue further ( like not zoom in/click data point). I am just a
little concerned about the usability part and not the functionality.
I don't think that the plot contains all that. In the example I have
seen, the X axis contained "year of release" and the Y axis was for
"popularity level from 1 to 9".
No I am saying that a lot of movies will have same year of release and same
There were buttons at the bottom to select genre but
this was not part
of the data points.
--
Marc Delisle
http://infomarc.info
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
10:20 a.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
2011/3/29 Ammar Yasir <ammaryasir.88(a)gmail.com>om>:
On Tue, Mar 29, 2011 at 5:01 PM, Marc Delisle <marc(a)infomarc.info> wrote:
One solution is to allow for adding random jitter to point coordinates
in order to scatter them around their real position, like it's done
for scatter plots in RapidMiner ([1], last screenshot).
[1] http://rapid-i.com/content/view/9/199/
--
Piotr Przybylski
Ammar Yasir a écrit :
No I am saying that a lot of movies will have same year of release and same
popularity. Those movie points will overlap on the 2D space, what then?
Thanks
I had a doubt (it might be silly but I thought I should ask). One
important feature of such a data visualization system is that it should
not create confusion or represent something that the data is not.
Consider the movie database example, when a user sees a plot of ratings
vs year / genre vs lanuage, a lot of data points will overlap. So a
lot of data will be hidden from the user at the first sight. What will a
user make out of it? I know we handle such conditions by providing all
the data instances when he clicks on the point but a user might not go
that far. If he is not able to understand the initial plot he might not
continue further ( like not zoom in/click data point). I am just a
little concerned about the usability part and not the functionality.
I don't think that the plot contains all that. In the example I have
seen, the X axis contained "year of release" and the Y axis was for
"popularity level from 1 to 9".
3 Apr
3 Apr
8:43 a.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
On Tue, Mar 29, 2011 at 6:50 PM, Piotr Przybylski <piotr.prz(a)gmail.com>wrote;wrote:
2011/3/29 Ammar Yasir
<ammaryasir.88(a)gmail.com>om>:
No I am saying that a lot of movies will have same year of release and
same
Yes, probably or like collisions resolution in hashing. I'll think on it
more.
I've submitted my proposal, hoping to get some feedback. Is it okay if we
concentrate more on a stable,usable product than implement many advanced
functionality? Because here it seems to be the case where we can add a lot
of statistics into the system.
On Tue, Mar 29, 2011 at 5:01 PM, Marc Delisle <marc(a)infomarc.info>
wrote:
>
> Ammar Yasir a écrit :
> >
> > Thanks
> >
> > I had a doubt (it might be silly but I thought I should ask). One
> > important feature of such a data visualization system is that it
should
> > not create confusion or represent
something that the data is not.
> > Consider the movie database example, when a user sees a plot of
ratings
> > vs year / genre vs lanuage, a lot of
data points will overlap. So a
> > lot of data will be hidden from the user at the first sight. What will
a
> > user make out of it? I know we handle
such conditions by providing all
> > the data instances when he clicks on the point but a user might not go
> > that far. If he is not able to understand the initial plot he might
not
continue further ( like not zoom in/click data point).
I am just a
little concerned about the usability part and not the functionality.
I don't think that the plot contains all that. In the example I have
seen, the X axis contained "year of release" and the Y axis was for
"popularity level from 1 to 9".
popularity. Those movie points will overlap on
the 2D space, what then?
One solution is to allow for adding random jitter to point coordinates
in order to scatter them around their real position, like it's done
for scatter plots in RapidMiner ([1], last screenshot).
[1] http://rapid-i.com/content/view/9/199/
--
Piotr Przybylski
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
8:58 a.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
Le 2011-04-03 07:43, Ammar Yasir a écrit :
Yes, probably or like collisions resolution in hashing. I'll think on it
more.
I've submitted my proposal, hoping to get some feedback. Is it okay if we
concentrate more on a stable,usable product than implement many advanced
functionality? Because here it seems to be the case where we can add a lot
of statistics into the system.
Choosing what is basic functionality and what is advanced, is open to
interpretation; a usability test with a group can tell you more.
--
Marc Delisle
http://infomarc.info
4 Apr
4 Apr
5:10 p.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
On Sun, Apr 3, 2011 at 5:28 PM, Marc Delisle <marc(a)infomarc.info> wrote:
Le 2011-04-03 07:43, Ammar Yasir a écrit :
Also, in the proposal should we mention exact working of the zooming tool?
I'm thinking that the functionality is fairly clear and many of available
plugins could well be of use. So we can maybe use those (with modifications
to our needs) instead of coding everything from scratch. It will also be
good if the zooming tool is something like they have used earlier e.g. like
google maps zooming. User might find such system more friendly.
Yes, probably or like collisions resolution in hashing. I'll think on it
more.
I've submitted my proposal, hoping to get some feedback. Is it okay if we
concentrate more on a stable,usable product than implement many advanced
functionality? Because here it seems to be the case where we can add a
lot
of statistics into the system.
Choosing what is basic functionality and what is advanced, is open to
interpretation; a usability test with a group can tell you more.
I agree. --
Marc Delisle
http://infomarc.info
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
8:56 p.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
Ammar Yasir a écrit :
On Sun, Apr 3, 2011 at 5:28 PM, Marc Delisle <marc(a)infomarc.info
<mailto:marc@infomarc.info>> wrote:
Le 2011-04-03 07:43, Ammar Yasir a écrit :
I don't think that the proposal should go too deep into implementation
details.
--
Marc Delisle
http://infomarc.info
Yes, probably or like collisions resolution in hashing. I'll
think on it
more.
I've submitted my proposal, hoping to get some feedback. Is it
okay if we
concentrate more on a stable,usable product than
implement many
advanced
functionality? Because here it seems to be the
case where we can
add a lot
of statistics into the system.
Choosing what is basic functionality and what is advanced, is open to
interpretation; a usability test with a group can tell you more.
I agree.
Also, in the proposal should we mention exact working of the zooming
tool? I'm thinking that the functionality is fairly clear and many of
available plugins could well be of use. So we can maybe use those (with
modifications to our needs) instead of coding everything from scratch.
It will also be good if the zooming tool is something like they have
used earlier e.g. like google maps zooming. User might find such system
more friendly.
6 Apr
6 Apr
3:01 a.m.
New subject: [Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
On Tue, Apr 5, 2011 at 5:26 AM, Marc Delisle <marc(a)infomarc.info> wrote:
Ammar Yasir a écrit :
Sir,
I was hoping if I could get some comments on my proposal once before the
deadline. I had submitted mine on 2nd.
On Sun, Apr 3, 2011 at 5:28 PM, Marc Delisle <marc(a)infomarc.info
<mailto:marc@infomarc.info>> wrote:
Le 2011-04-03 07:43, Ammar Yasir a écrit :
I don't think that the proposal should go too deep into implementation
details.
Yes, probably or like collisions resolution in hashing. I'll
think on it
more.
I've submitted my proposal, hoping to get some feedback. Is it
okay if we
concentrate more on a stable,usable product than
implement many
advanced
functionality? Because here it seems to be the
case where we can
add a lot
of statistics into the system.
Choosing what is basic functionality and what is advanced, is open to
interpretation; a usability test with a group can tell you more.
I agree.
Also, in the proposal should we mention exact working of the zooming
tool? I'm thinking that the functionality is fairly clear and many of
available plugins could well be of use. So we can maybe use those (with
modifications to our needs) instead of coding everything from scratch.
It will also be good if the zooming tool is something like they have
used earlier e.g. like google maps zooming. User might find such system
more friendly.
--
Marc Delisle
http://infomarc.info
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
4903
days inactive
4912
days old
8 comments
3 participants
participants (3)
-
Ammar Yasir -
Marc Delisle -
Piotr Przybylski