[Phpmyadmin-devel] GSoG 2011: Reg Zoom-search idea
Hi, We are supposed to select two columns from the table. I wanted to ask that whether we would also have to provide some sort of query interface so that you can select some instance of the column. eg Table -> Movies Column1 -> Popularity | Popularity > 7.5 Column2 -> Year | Year = 2010 Ammar Yasir
Le 2011-03-18 16:15, Ammar Yasir a écrit :
Hi, We are supposed to select two columns from the table. I wanted to ask that whether we would also have to provide some sort of query interface so that you can select some instance of the column. eg Table -> Movies Column1 -> Popularity | Popularity > 7.5 Column2 -> Year | Year = 2010
Ammar Yasir
Yes, so you might explore the possibility of combining the existing table Search page (which already permits such selections) with the zoom-search. -- Marc Delisle http://infomarc.info
Sir, I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further? Regards, Ammar Yasir On Sat, Mar 19, 2011 at 4:38 PM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-18 16:15, Ammar Yasir a écrit :
Hi, We are supposed to select two columns from the table. I wanted to ask that whether we would also have to provide some sort of query interface so that you can select some instance of the column. eg Table -> Movies Column1 -> Popularity | Popularity > 7.5 Column2 -> Year | Year = 2010
Ammar Yasir
Yes, so you might explore the possibility of combining the existing table Search page (which already permits such selections) with the zoom-search.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow). I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages. You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion. Try to avoid a behavior that would be too sequential.
Regards, Ammar Yasir
On Sat, Mar 19, 2011 at 4:38 PM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-18 16:15, Ammar Yasir a écrit :
Hi, We are supposed to select two columns from the table. I wanted to ask that whether we would also have to provide some sort of query interface so that you can select some instance of the column. eg Table -> Movies Column1 -> Popularity | Popularity > 7.5 Column2 -> Year | Year = 2010
Ammar Yasir
Yes, so you might explore the possibility of combining the existing table Search page (which already permits such selections) with the zoom-search.
-- Marc Delisle http://infomarc.info
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen. Try to avoid a behavior that would be too sequential.
and this will not be very sequential also. For example see: Initially -> http://web.iiit.ac.in/~yasir/IMG1.jpg , Selecting File_priv -> http://web.iiit.ac.in/~yasir/IMG2.jpg
Regards, Ammar Yasir
On Sat, Mar 19, 2011 at 4:38 PM, Marc Delisle <marc@infomarc.info>
wrote:
Le 2011-03-18 16:15, Ammar Yasir a écrit :
Hi, We are supposed to select two columns from the table. I wanted to ask that whether we would also have to provide some sort of query interface so that you can select some instance of the column. eg Table -> Movies Column1 -> Popularity | Popularity > 7.5 Column2 -> Year | Year = 2010
Ammar Yasir
Yes, so you might explore the possibility of combining the existing table Search page (which already permits such selections) with the zoom-search.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-03-19 17:35, Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
This should work but the user needs to select two columns, not just one.
Try to avoid a behavior that would be too sequential.
and this will not be very sequential also. For example see: Initially -> http://web.iiit.ac.in/~yasir/IMG1.jpg , Selecting File_priv -> http://web.iiit.ac.in/~yasir/IMG2.jpg
Fine. -- Marc Delisle http://infomarc.info
On Sun, Mar 20, 2011 at 3:02 PM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 17:35, Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
This should work but the user needs to select two columns, not just one.
We can put a constant on the number of search criteria to 2, so you'll have to select exactly two columns.
One more thing, can the two columns be from different tables also. Like for example, for a house auction database: There is a 'house' table (neighborhood,address,no_of_rooms,plot_size....) and a sales table (selling_price,date_sold,....) and the user might want to see a visualization of plot_size vs selling_price. Do you think I am going off the project idea? This would involve using underlying relationship between the house table and sales table and it would be fairly complex to develop such system.
Try to avoid a behavior that would be too sequential.
and this will not be very sequential also. For example see: Initially -> http://web.iiit.ac.in/~yasir/IMG1.jpg , Selecting File_priv -> http://web.iiit.ac.in/~yasir/IMG2.jpg
Fine.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-03-20 06:14, Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 3:02 PM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 17:35, Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
This should work but the user needs to select two columns, not just one.
We can put a constant on the number of search criteria to 2, so you'll have to select exactly two columns.
One more thing, can the two columns be from different tables also. Like for example, for a house auction database: There is a 'house' table (neighborhood,address,no_of_rooms,plot_size....) and a sales table (selling_price,date_sold,....) and the user might want to see a visualization of plot_size vs selling_price.
Do you think I am going off the project idea? This would involve using underlying relationship between the house table and sales table and it would be fairly complex to develop such system.
Yes it could. I'm not saying that this project has to support this, however. Do you know about the multi-tables query generator? You click on a database name, then Query. This has been there for many years and in version 3.4 there is a visual mode. This feature generates the multi-table query, based on existing relations (only from internal relations, sadly not yet for Innodb-style relations, see FAQ 3.6). Can we conclude that whatever way is used to generate the query, the zoom-search mode could be used when we have a results set containing two columns? -- Marc Delisle http://infomarc.info
On Sun, Mar 20, 2011 at 3:54 PM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-20 06:14, Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 3:02 PM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 17:35, Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
This should work but the user needs to select two columns, not just one.
We can put a constant on the number of search criteria to 2, so you'll have to select exactly two columns.
One more thing, can the two columns be from different tables also. Like for example, for a house auction database: There is a 'house' table (neighborhood,address,no_of_rooms,plot_size....) and a sales table (selling_price,date_sold,....) and the user might want to see a visualization of plot_size vs selling_price.
Do you think I am going off the project idea? This would involve using underlying relationship between the house table and sales table and it would be fairly complex to develop such system.
Yes it could. I'm not saying that this project has to support this, however.
Do you know about the multi-tables query generator? You click on a database name, then Query. This has been there for many years and in version 3.4 there is a visual mode. This feature generates the multi-table query, based on existing relations (only from internal relations, sadly not yet for Innodb-style relations, see FAQ 3.6).
I totally forgot about that feature. This interface can combine well with visualizing query results spanning multiple tables.
Can we conclude that whatever way is used to generate the query, the zoom-search mode could be used when we have a results set containing two columns?
Yes, I agree with this. So for the visualization part, there is one point mentioned that when we zoom in for example in the movies database case we see the movie's title. How is that to be decided that what label to show for a point? Should the user input this or does the system comes up with a label(like a key for each point)? Also, I submitted a patch for mass table prefix change. May someone look at it and confirm? I had made changes to the original patch but I didn't get any comments further. Regards, Ammar Yasir
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-03-20 15:22, Ammar Yasir a écrit :
Can we conclude that whatever way is used to generate the query, the zoom-search mode could be used when we have a results set containing two columns?
Yes, I agree with this. So for the visualization part, there is one point mentioned that when we zoom in for example in the movies database case we see the movie's title. How is that to be decided that what label to show for a point? Should the user input this or does the system comes up with a label(like a key for each point)?
I don't see how phpMyAdmin could decide which column to choose as a label, so it will have to be input by the user. But it could be saved in the phpMyAdmin configuration storage for reuse, like we do in the pma_table_info with the "display_field" that is used for internal relation.
Also, I submitted a patch for mass table prefix change. May someone look at it and confirm? I had made changes to the original patch but I didn't get any comments further.
Yes, one of the team members will look at it when he finds time :) -- Marc Delisle http://infomarc.info
On Mon, Mar 21, 2011 at 2:57 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-20 15:22, Ammar Yasir a écrit :
Can we conclude that whatever way is used to generate the query, the zoom-search mode could be used when we have a results set containing two columns?
Yes, I agree with this. So for the visualization part, there is one point mentioned that when we zoom in for example in the movies database case we see the movie's title. How is that to be decided that what label to show
for
a point? Should the user input this or does the system comes up with a label(like a key for each point)?
I don't see how phpMyAdmin could decide which column to choose as a label, so it will have to be input by the user. But it could be saved in the phpMyAdmin configuration storage for reuse, like we do in the pma_table_info with the "display_field" that is used for internal relation.
Also, I submitted a patch for mass table prefix change. May someone look
at
it and confirm? I had made changes to the original patch but I didn't get any comments further.
Yes, one of the team members will look at it when he finds time :)
Thanks, someone did look it up.
May I ask what quality aspect should this system focus on. It should be correct, but what about trade off between system response time and functionality. Like for example, Zooming feature. Should it be like from 1X->2X or should the image magnify gradually. Since pchart will produce static images, some of these issues will be faced while designing.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Ammar Yasir a écrit :
May I ask what quality aspect should this system focus on. It should be correct, but what about trade off between system response time and functionality. Like for example, Zooming feature. Should it be like from 1X->2X or should the image magnify gradually. Since pchart will produce static images, some of these issues will be faced while designing.
I would prefer a gradual zoom but haven't made any research about how to implement this. If pChart is not the best tool for this, you can look for a better one. The other day I mentionned pChart because we are currently using it (in phpMyAdmin 3.4) for static charts. OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine. -- Marc Delisle http://infomarc.info
On Tue, Mar 22, 2011 at 11:24 PM, Marc Delisle <marc@infomarc.info> wrote:
Ammar Yasir a écrit :
May I ask what quality aspect should this system focus on. It should be correct, but what about trade off between system response time and functionality. Like for example, Zooming feature. Should it be like from 1X->2X or should the image magnify gradually. Since pchart will produce static images, some of these issues will be faced while designing.
I would prefer a gradual zoom but haven't made any research about how to implement this. If pChart is not the best tool for this, you can look for a better one. The other day I mentionned pChart because we are currently using it (in phpMyAdmin 3.4) for static charts.
So, is it like we can use any type of zoom but whenever the number of points in the screen fall below a certain number, we show labels?
Also, I think in pChart its not very straight forward to implement clickable items(click data points to view data row). We would have to use CSS with overlaid items.
OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine.
I also have never implemented such but I found something on the net, http://www.cssplay.co.uk/menu/image_magnifier2.html . I'll try to look for something like this.
-- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Ammar Yasir a écrit :
On Tue, Mar 22, 2011 at 11:24 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Ammar Yasir a écrit :
> May I ask what quality aspect should this system focus on. It should be > correct, but what about trade off between system response time and > functionality. Like for example, Zooming feature. Should it be like from > 1X->2X or should the image magnify gradually. Since pchart will produce > static images, some of these issues will be faced while designing.
I would prefer a gradual zoom but haven't made any research about how to implement this. If pChart is not the best tool for this, you can look for a better one. The other day I mentionned pChart because we are currently using it (in phpMyAdmin 3.4) for static charts.
So, is it like we can use any type of zoom but whenever the number of points in the screen fall below a certain number, we show labels?
I think it's more when the user ceases to see big clusters of data points and is able to perceive the distinct points.
Also, I think in pChart its not very straight forward to implement clickable items(click data points to view data row). We would have to use CSS with overlaid items.
OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine.
I also have never implemented such but I found something on the net, http://www.cssplay.co.uk/menu/image_magnifier2.html . I'll try to look for something like this.
-- Marc Delisle http://infomarc.info
2011/3/22 Marc Delisle <marc@infomarc.info>:
Ammar Yasir a écrit :
On Tue, Mar 22, 2011 at 11:24 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Ammar Yasir a écrit :
> May I ask what quality aspect should this system focus on. It should be > correct, but what about trade off between system response time and > functionality. Like for example, Zooming feature. Should it be like from > 1X->2X or should the image magnify gradually. Since pchart will produce > static images, some of these issues will be faced while designing.
I would prefer a gradual zoom but haven't made any research about how to implement this. If pChart is not the best tool for this, you can look for a better one. The other day I mentionned pChart because we are currently using it (in phpMyAdmin 3.4) for static charts.
So, is it like we can use any type of zoom but whenever the number of points in the screen fall below a certain number, we show labels?
I think it's more when the user ceases to see big clusters of data points and is able to perceive the distinct points.
Also, I think in pChart its not very straight forward to implement clickable items(click data points to view data row). We would have to use CSS with overlaid items.
OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine.
I also have never implemented such but I found something on the net, http://www.cssplay.co.uk/menu/image_magnifier2.html . I'll try to look for something like this.
Maybe SVG? Vector output would give users faster feedback (no need to generate big bitmaps on the server and send them) and allow for fluent scaling in browser. Recently even IE got native support, with the release of IE 9. -- Piotr Przybylski
On Wed, Mar 23, 2011 at 1:01 AM, Piotr Przybylski <piotr.prz@gmail.com>wrote:
2011/3/22 Marc Delisle <marc@infomarc.info>:
Ammar Yasir a écrit :
On Tue, Mar 22, 2011 at 11:24 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Ammar Yasir a écrit :
> May I ask what quality aspect should this system focus on. It should be > correct, but what about trade off between system response time
and
> functionality. Like for example, Zooming feature. Should it be like from > 1X->2X or should the image magnify gradually. Since pchart will produce > static images, some of these issues will be faced while
designing.
I would prefer a gradual zoom but haven't made any research about
how to
implement this. If pChart is not the best tool for this, you can
look
for a better one. The other day I mentionned pChart because we are currently using it (in phpMyAdmin 3.4) for static charts.
So, is it like we can use any type of zoom but whenever the number of points in the screen fall below a certain number, we show labels?
I think it's more when the user ceases to see big clusters of data points and is able to perceive the distinct points.
Also, I think in pChart its not very straight forward to implement clickable items(click data points to view data row). We would have to use CSS with overlaid items.
OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine.
I also have never implemented such but I found something on the net, http://www.cssplay.co.uk/menu/image_magnifier2.html . I'll try to look for something like this.
Maybe SVG? Vector output would give users faster feedback (no need to generate big bitmaps on the server and send them) and allow for fluent scaling in browser. Recently even IE got native support, with the release of IE 9.
What about JpGraph?
-- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2011/3/23 Ammar Yasir <ammaryasir.88@gmail.com>:
On Wed, Mar 23, 2011 at 1:01 AM, Piotr Przybylski <piotr.prz@gmail.com> wrote:
2011/3/22 Marc Delisle <marc@infomarc.info>:
Ammar Yasir a écrit :
On Tue, Mar 22, 2011 at 11:24 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Ammar Yasir a écrit :
> May I ask what quality aspect should this system focus on. It should be > correct, but what about trade off between system response time and > functionality. Like for example, Zooming feature. Should it be like from > 1X->2X or should the image magnify gradually. Since pchart will produce > static images, some of these issues will be faced while designing.
I would prefer a gradual zoom but haven't made any research about how to implement this. If pChart is not the best tool for this, you can look for a better one. The other day I mentionned pChart because we are currently using it (in phpMyAdmin 3.4) for static charts.
So, is it like we can use any type of zoom but whenever the number of points in the screen fall below a certain number, we show labels?
I think it's more when the user ceases to see big clusters of data points and is able to perceive the distinct points.
Also, I think in pChart its not very straight forward to implement clickable items(click data points to view data row). We would have to use CSS with overlaid items.
OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine.
I also have never implemented such but I found something on the net, http://www.cssplay.co.uk/menu/image_magnifier2.html . I'll try to look for something like this.
Maybe SVG? Vector output would give users faster feedback (no need to generate big bitmaps on the server and send them) and allow for fluent scaling in browser. Recently even IE got native support, with the release of IE 9.
What about JpGraph?
JpGraph generates bitmaps, I am proposing SVG to avoid this and provide scaling in browser. With bitmap output any panning and zooming will require round trips to server and execution of (almost) the same query again. With SVG you can generate one image and process it in browser. It will give users faster feedback and save us from including another charting library. -- Piotr Przybylski
On Wed, Mar 23, 2011 at 4:33 PM, Piotr Przybylski <piotr.prz@gmail.com>wrote:
2011/3/23 Ammar Yasir <ammaryasir.88@gmail.com>:
On Wed, Mar 23, 2011 at 1:01 AM, Piotr Przybylski <piotr.prz@gmail.com> wrote:
2011/3/22 Marc Delisle <marc@infomarc.info>:
Ammar Yasir a écrit :
On Tue, Mar 22, 2011 at 11:24 PM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Ammar Yasir a écrit :
> May I ask what quality aspect should this system focus on. It should be > correct, but what about trade off between system response time and > functionality. Like for example, Zooming feature. Should it be like from > 1X->2X or should the image magnify gradually. Since pchart
will
produce > static images, some of these issues will be faced while designing.
I would prefer a gradual zoom but haven't made any research about how to implement this. If pChart is not the best tool for this, you can look for a better one. The other day I mentionned pChart because we
are
currently using it (in phpMyAdmin 3.4) for static charts.
So, is it like we can use any type of zoom but whenever the number of points in the screen fall below a certain number, we show labels?
I think it's more when the user ceases to see big clusters of data points and is able to perceive the distinct points.
Also, I think in pChart its not very straight forward to implement clickable items(click data points to view data row). We would have
to
use CSS with overlaid items.
OTOH if there is no open tool for a gradual zoom (web), going in increments (say, with buttons) will be fine.
I also have never implemented such but I found something on the net, http://www.cssplay.co.uk/menu/image_magnifier2.html . I'll try to look for something like this.
Maybe SVG? Vector output would give users faster feedback (no need to generate big bitmaps on the server and send them) and allow for fluent scaling in browser. Recently even IE got native support, with the release of IE 9.
What about JpGraph?
JpGraph generates bitmaps, I am proposing SVG to avoid this and provide scaling in browser. With bitmap output any panning and zooming will require round trips to server and execution of (almost) the same query again. With SVG you can generate one image and process it in browser. It will give users faster feedback and save us from including another charting library.
I looked around if we can use SVG for this. One thing I found everyone saying was that SVG integration with HTML, particularly with inline SVG is someway incomplete. Is it so? Also, i looked up on jquerySVG(http://keith-wood.name/svg.html). This can provide for most of the functionality required here.
-- Piotr Przybylski
On Sun, Mar 20, 2011 at 3:05 AM, Ammar Yasir <ammaryasir.88@gmail.com>wrote:
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit :
Sir,
I looked at the table search page. One problem I find is that a form such as table search page consists of all the columns. I think in general a user is interested in at most 2-3 criteria for searching at once. If number of columns are more(in a table eg. users table in mysql database), the search table form will contain lot of irrelevant fields(to his query). Can the page be something like it asks the user to select the column first, then its detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
Try to avoid a behavior that would be too sequential.
and this will not be very sequential also. For example see: Initially -> http://web.iiit.ac.in/~yasir/IMG1.jpg , Selecting File_priv -> http://web.iiit.ac.in/~yasir/IMG2.jpg
Hi,
Regarding the table search page, should I try doing the changes ( see images above) i.e. changing from a query-by-example to displaying fields on user click (on a column). Maybe they could turn out useful if we test??
Regards, Ammar Yasir
On Sat, Mar 19, 2011 at 4:38 PM, Marc Delisle <marc@infomarc.info>
wrote:
Le 2011-03-18 16:15, Ammar Yasir a écrit :
Hi, We are supposed to select two columns from the table. I wanted to ask that whether we would also have to provide some sort of query interface so that you can select some instance of the column. eg Table -> Movies Column1 -> Popularity | Popularity > 7.5 Column2 -> Year | Year = 2010
Ammar Yasir
Yes, so you might explore the possibility of combining the existing table Search page (which already permits such selections) with the zoom-search.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 3:05 AM, Ammar Yasir <ammaryasir.88@gmail.com <mailto:ammaryasir.88@gmail.com>> wrote:
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit : > Sir, > > I looked at the table search page. One problem I find is that a form such as > table search page consists of all the columns. I think in general a user is > interested in at most 2-3 criteria for searching at once. If number of > columns are more(in a table eg. users table in mysql database), the search > table form will contain lot of irrelevant fields(to his query). Can the page > be something like it asks the user to select the column first, then its > detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to avoid duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive a search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
Try to avoid a behavior that would be too sequential.
and this will not be very sequential also. For example see: Initially -> http://web.iiit.ac.in/~yasir/IMG1.jpg <http://web.iiit.ac.in/%7Eyasir/IMG1.jpg> , Selecting File_priv ->http://web.iiit.ac.in/~yasir/IMG2.jpg <http://web.iiit.ac.in/%7Eyasir/IMG2.jpg>
Hi, Regarding the table search page, should I try doing the changes ( see images above) i.e. changing from a query-by-example to displaying fields on user click (on a column). Maybe they could turn out useful if we test??
Yes but this table is a special case with a lot of ENUMs. I don't see in your screenshot where a user would give an example value, let's say for "host". I suggest you use the "sakila" example database which contains more real-world tables. -- Marc Delisle http://infomarc.info
On Mon, Apr 11, 2011 at 10:19 PM, Marc Delisle <marc@infomarc.info> wrote:
Ammar Yasir a écrit :
On Sun, Mar 20, 2011 at 3:05 AM, Ammar Yasir <ammaryasir.88@gmail.com <mailto:ammaryasir.88@gmail.com>> wrote:
On Sun, Mar 20, 2011 at 2:00 AM, Marc Delisle <marc@infomarc.info <mailto:marc@infomarc.info>> wrote:
Le 2011-03-19 15:13, Ammar Yasir a écrit : > Sir, > > I looked at the table search page. One problem I find is that a form such as > table search page consists of all the columns. I think in general a user is > interested in at most 2-3 criteria for searching at once. If number of > columns are more(in a table eg. users table in mysql database), the search > table form will contain lot of irrelevant fields(to his query). Can the page > be something like it asks the user to select the column first, then its > detail and then again a column if he wants to build the query further?
(Please do not top-post, conversations are difficult to follow).
I was referring to the Table Search page because we'll have to
avoid
duplicating the same functionality on many pages.
You are right, the table Search page displays all the columns in "query by example" but in its Options hidden panel you can choose the columns that will be displayed. I think that this behavior could be improved by adding a way to quickly hide or show which columns are to receive
a
search criterion.
I think that we can reduce some fields by combining elements from the table search page and those from the options hidden pane. The table search form provides appropriate operations for each column and in options panel we can select columns but it just provides a textbox to enter the body of the WHERE clause.
As in this case we are only interested in selecting one of the columns, initially we can just have a list of columns and then when a user clicks on one of the columns, the appropriate operations available for that column appear. This reduces some of the fields on the screen.
Try to avoid a behavior that would be too sequential.
and this will not be very sequential also. For example see: Initially -> http://web.iiit.ac.in/~yasir/IMG1.jpg <http://web.iiit.ac.in/%7Eyasir/IMG1.jpg> , Selecting File_priv ->http://web.iiit.ac.in/~yasir/IMG2.jpg <http://web.iiit.ac.in/%7Eyasir/IMG2.jpg>
Hi, Regarding the table search page, should I try doing the changes ( see images above) i.e. changing from a query-by-example to displaying fields on user click (on a column). Maybe they could turn out useful if we
test??
Yes but this table is a special case with a lot of ENUMs. I don't see in your screenshot where a user would give an example value, let's say for "host".
I suggest you use the "sakila" example database which contains more real-world tables.
Hi,
I just submitted a patch for this. Its just a basic idea of what I though would help in that interface. It might not look good on applying, so if you may please give comments to improve.
-- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
participants (3)
-
Ammar Yasir -
Marc Delisle -
Piotr Przybylski