Hi!
The first time for maybe 2 years I am in need of using phpMyAdmin intensively again, and now had a closer look on the current SVN trunk (3.2.0-dev), where I was surprised to see some common usage cases changed in a way, that makes my life harder to use phpMyAdmin.
I would like to put some work into that, but first ask for the reasoning behind if, and if my work on that is appreciated. Mind me that I have not yet read the sourcecode on these issues, so I might not be aware of any hidden config options that toggle this changed behaviour.
* On the table structure page, the indices have been hidden by default. For me and for many others, Indexes are REALLY important for MySQL administration. Having an additional click on "+ Details" (which needs some specific designing/icon for the future) to expand those details is slowing things down.
I suggest to either add a config option to be able to turn on the Details by default again, with the values "Yes, No, Cookie". When choosing Cookie, a per-table cookie would be created that indicates if the indices are shown by default or not.
Also, the "Details" link appears below the repeated navigation for tables with many keys. I suggest to have Details BEFORE the repeated navigation.
Plus, when clicking on "Details" on tables with many keys, the browser jumps to the top of the page, and I need to scroll down again to see the actual indexes.
* Much more problematic for my own work is that when I browse tables, the "FULLTEXT" icon was removed. What was formerly one click to reveal larger table contents is now three clicks, and needs to be performed for every pagination resultset. That really curbs down easy access to table contents.
I suggest to re-add the Fulltext toggle icon. The other content of "+ Options" when browsing can stay how it is can stay, I think those options are used fairly rarely.
Plus, when expanding the "+Options", the browser cuts of the last 2-3 pixels of the box, so no ending border remains and it makes the whole dropout appear a bit ugly. ;)
* The actions for browsing a table and viewing the structure from the left frame has been reversed. What is the reasoning behind this? I think many users got accustomed to that, so switching it is hard to understand, as I also see no real benefit to the change other than creating confusion?
I'm eager to hear your feedback on this. :-)
Best regards, Garvin
Garvin Hicking a écrit :
Hi!
The first time for maybe 2 years I am in need of using phpMyAdmin intensively again, and now had a closer look on the current SVN trunk (3.2.0-dev), where I was surprised to see some common usage cases changed in a way, that makes my life harder to use phpMyAdmin.
I would like to put some work into that, but first ask for the reasoning behind if, and if my work on that is appreciated. Mind me that I have not yet read the sourcecode on these issues, so I might not be aware of any hidden config options that toggle this changed behaviour.
- On the table structure page, the indices have been hidden by default. For me
and for many others, Indexes are REALLY important for MySQL administration. Having an additional click on "+ Details" (which needs some specific designing/icon for the future) to expand those details is slowing things down.
Hi Garvin, I think this directive will help you:
$cfg['InitialSlidersState'] string If set to 'closed', the visual sliders are initially in a closed state. A value of 'open' does the reverse.
But to confirm your point, we got another feedback that it's not a good idea to hide something if it's already at the bottom of screen.
I suggest to either add a config option to be able to turn on the Details by default again, with the values "Yes, No, Cookie". When choosing Cookie, a per-table cookie would be created that indicates if the indices are shown by default or not.
Also, the "Details" link appears below the repeated navigation for tables with many keys. I suggest to have Details BEFORE the repeated navigation.
Plus, when clicking on "Details" on tables with many keys, the browser jumps to the top of the page, and I need to scroll down again to see the actual indexes.
- Much more problematic for my own work is that when I browse tables, the
"FULLTEXT" icon was removed. What was formerly one click to reveal larger table contents is now three clicks, and needs to be performed for every pagination resultset. That really curbs down easy access to table contents.
I suggest to re-add the Fulltext toggle icon. The other content of "+ Options" when browsing can stay how it is can stay, I think those options are used fairly rarely.
Plus, when expanding the "+Options", the browser cuts of the last 2-3 pixels of the box, so no ending border remains and it makes the whole dropout appear a bit ugly. ;)
Yes, please provide us a patch ;)
- The actions for browsing a table and viewing the structure from the left frame
has been reversed. What is the reasoning behind this? I think many users got accustomed to that, so switching it is hard to understand, as I also see no real benefit to the change other than creating confusion?
The reasoning is that browsing a table is (probably) more common than accessing the structure, and clicking on the table name is easier than clicking on the small icon. But then, you have
$cfg['LeftDefaultTabTable'] // for the icon and $cfg['DefaultTabTable'] // for clicking on table name
I'm eager to hear your feedback on this. :-)
Best regards, Garvin
Hi!
$cfg['InitialSlidersState'] string If set to 'closed', the visual sliders are initially in a closed state. A value of 'open' does the reverse.
Ah, perfect - that does the job for me. Would be nice to have that in the setup script, but I think that this is being reworked already, right?
But to confirm your point, we got another feedback that it's not a good idea to hide something if it's already at the bottom of screen.
I'd definitely suggest to make it default to "open".
[Remembering Fulltext toggle in cookie
Yes, please provide us a patch ;)
Okay, I'll try to make that work, and make an optional "cookie" value for InitialSlidersState, yes?
The reasoning is that browsing a table is (probably) more common than accessing the structure, and clicking on the table name is easier than clicking on the small icon. But then, you have
$cfg['LeftDefaultTabTable'] // for the icon and $cfg['DefaultTabTable'] // for clicking on table name
I agree about it maybe being more common for some users. But I disagree on having that as the default, because it really breaks the user's expectancy. phpMyadmin has been available for so long a time, so I don't really suggest to change expected things for clicks that provide no real benefit... :)
Best regards, Garvin
Garvin Hicking a écrit :
Hi!
$cfg['InitialSlidersState'] string If set to 'closed', the visual sliders are initially in a closed state. A value of 'open' does the reverse.
Ah, perfect - that does the job for me. Would be nice to have that in the setup script, but I think that this is being reworked already, right?
I'm not sure. Maybe Piotr can answer.
But to confirm your point, we got another feedback that it's not a good idea to hide something if it's already at the bottom of screen.
I meant, hiding a section like Indexes which is already at the bottom.
I'd definitely suggest to make it default to "open".
I don't agree, this would defeat the purpose of these sliders, since most people do not change defaults.
[Remembering Fulltext toggle in cookie
Yes, please provide us a patch ;)
Okay, I'll try to make that work, and make an optional "cookie" value for InitialSlidersState, yes?
I meant a patch for the pixel problem. In general, we don't need more cookies, we mostly need db-based user preferences.
The reasoning is that browsing a table is (probably) more common than accessing the structure, and clicking on the table name is easier than clicking on the small icon. But then, you have
$cfg['LeftDefaultTabTable'] // for the icon and $cfg['DefaultTabTable'] // for clicking on table name
I agree about it maybe being more common for some users. But I disagree on having that as the default, because it really breaks the user's expectancy. phpMyadmin has been available for so long a time, so I don't really suggest to change expected things for clicks that provide no real benefit... :)
It provides a real benefit because me and others believe it's the most common action for the most users. It's true that it breaks old users' expectancy, we knew it would happen but for the future it's better this way.
Best regards, Garvin
-
Garvin Hicking -
Marc Delisle