I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability. Especially once you've added 2 more columns. The idea of AJAXifying pma is to increase the usability, but with a small dialog where I have to scroll horizontally and vertically several time to create the table, it will take me way way longer compared to the old create-table interface.
I don't know if its just me, but I see so many things gone wrong with this dialog.
Some things I would change globally (taking the create table dialog as example) : - Decrease the massive amounts of padding/margin of the jquery ui dialogs. - I don't need a 40 pixel high title telling me that I'm currently creating a table. - Did you notice that there's is a 900 x 60 pixel (!) area that only performs a single function: Containing the cancel button. This should be either drastically reduced in size or removed altogether (and put the cancel button inside the content) - Decrease those massive margins and paddings around input fields. Those should be made big only where it actually improves the usability/readability. I would reduce the margin/padding from 6/4 to 2/2
And for the create table dialog: - Display always in horizontal mode! Hardly any tables contain just 2 columns. - Start always with 4 fields - Bug: You can actually open the dialog several times, cause the enum/set editor to be in the background - Make all selects and text inputs way shorter. I'd reduce them by ~30% (selects as well!). The length/value field I would reduce by 50-70% or so. - The null and A_I checkbox waste big amounts of space. I would put them together in the form of " [ ] Null [ ] A_I " in a column called "Options" - Remove the "Table name:" title, instead put 'Table name' into the input field that disappears once the user focuses it - Instead of "Add x tables [Go]" which does it's own ajax request I would place a link "Add column" that adds one single column, but therefore adds it immediately (no ajax here!), allowing users to just spam click the link if they need a lot. Or alternatively use a select list that contains the numbers from 1 to 10 which adds columns immediately on the onchange event. - Display the input field for the default value only after "As defined:" is selected, and also focus it automatically once its selected so the user can type immediately - Why do we have these footnotes at the bottom of the dialog when we got PMA_showHint()? (Forgot to initialize them in js?) - For all the form fields below the columns: Remove all the gradient backgrounds on the titles. What are they there for? - In whatever way, put the Save and Cancel button side by side
- The enum/set editor I find so bad, I don't even know how you could improve that: - If my table would be having 3 enums, I get 3 times this sentenced thrown onto my screen causing the columns table to get even bigger. - The dialog itself has a completely different style than everything else in PMA and really badly implemented. Just some bugs: - Values for column "" - wheres the column name? - Why is "Go" a button and "Cancel" a link? - Single quotes are not escaped (put a ' into the value field) - Breaks if a user accidently enters a space - The background is grayed out, yet you can still interact with it (e.g. select text) - You can actually scroll away the content of the dialog by selecting text downwards - Visual bug: One can see all input fields disappear if you press ok/cancel
- Why not just a simple textfield where you let the user write one value per line? I would build the enum/set like this: - if set/enum is selected and the user focuses on the input field, pop out a bigger textarea (that is placed like a datepicker) - let the user write one element per line - extend the textarea row height with every line written so the user doesn't have to scroll. (up to a certain limit of course, like 15-20 lines - also it should not force the to scroll the page) - with every line written or on lost focus, automatically parse the text and update the value field correctly formatted
Now lets say my enum has 5 elements. With the current enum/set editor that would require me to perform 13 mouse clicks and 5 interruptions (where my hands need to switch between mouse and keyboard), whereas with a textarea that pops up like a datepicker requires 2 mouse clicks and 0 interruptions. Why build things so complicated? ;-)
Sorry again if I sounded too unpolite :<
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
1. the AJAX create table dialog
2. the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
On Sat, 2011-06-25 at 08:29 -0400, Marc Delisle wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Another issue is that the content inside the ajax dialog is rendered at 1.1em, whereas on the non-ajax page the content is rendered at 1em. So the same content when in ajax mode takes up 10% more space.
Rouslan
Le 2011-06-25 08:43, Rouslan Placella a écrit :
On Sat, 2011-06-25 at 08:29 -0400, Marc Delisle wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Another issue is that the content inside the ajax dialog is rendered at 1.1em, whereas on the non-ajax page the content is rendered at 1em. So the same content when in ajax mode takes up 10% more space.
Rouslan
Can someone have a look at the dialogClass option of jQuery UI dialog? "The specified class name(s) will be added to the dialog, for additional theming."
http://jqueryui.com/demos/dialog/#option-dialogClass
Hi
Dne Sat, 25 Jun 2011 13:43:20 +0100 Rouslan Placella rouslan@placella.com napsal(a):
Another issue is that the content inside the ajax dialog is rendered at 1.1em, whereas on the non-ajax page the content is rendered at 1em. So the same content when in ajax mode takes up 10% more space.
I don't see much reasons why the dialogs should use different fonts and font size than main frame. This probably comes from default jQuery CSS and nobody cared to change that.
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
-- Marc Delisle http://infomarc.info
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-06-25 08:56, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
I'm not sure that we can span a dialog over the other frame. Besides, the idea of the navigation frame is to have a reference spot that is always available.
On Sat, Jun 25, 2011 at 4:07 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-06-25 08:56, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
I'm not sure that we can span a dialog over the other frame.
Yea, such feature will probably only work after framesets have been removed, which should be done in the not so far future, I think
Besides, the idea of the navigation frame is to have a reference spot that is always available.
Why would someone need the navigation frame to be visible when a dialog is open? If he needs to navigate away, a click on the ESC button and he can do so again. The gain from having more space would be greater than the inconvenience of not seeing the navigation frame, I think.
-- Marc Delisle http://infomarc.info
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-06-25 11:11, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 4:07 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:56, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
I'm not sure that we can span a dialog over the other frame.
... but at least the dialog could span the main frame.
Yea, such feature will probably only work after framesets have been removed, which should be done in the not so far future, I think
Do you suggest this removal for 3.5? I don't think that this has been agreed to (at least for 3.5).
Besides, the idea of the navigation frame is to have a reference spot that is always available.
Why would someone need the navigation frame to be visible when a dialog is open? If he needs to navigate away, a click on the ESC button and he can do so again. The gain from having more space would be greater than the inconvenience of not seeing the navigation frame, I think.
Your argument makes sense.
On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-06-25 11:11, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 4:07 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:56, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit :
I apologize for my directness but the newly implemented 'Create table' Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
I'm not sure that we can span a dialog over the other frame.
... but at least the dialog could span the main frame.
Yea, such feature will probably only work after framesets have been removed, which should be done in the not so far future, I think
Do you suggest this removal for 3.5? I don't think that this has been agreed to (at least for 3.5).
Probably not for 3.5. Maybe it could be part of a project for gsoc next year? Part of a code cleanup project, or something.
Besides, the idea of the navigation frame is to have a reference spot that is always available.
Why would someone need the navigation frame to be visible when a dialog is open? If he needs to navigate away, a click on the ESC button and he can do so again. The gain from having more space would be greater than the inconvenience of not seeing the navigation frame, I think.
Your argument makes sense.
-- Marc Delisle http://infomarc.info
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Sat, Jun 25, 2011 at 6:26 PM, Tyron Madlener tyronx@gmail.com wrote:
On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-06-25 11:11, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 4:07 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:56, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:07, Tyron Madlener a écrit : > I apologize for my directness but the newly implemented 'Create table' > Dialog has an awful usability.
Tyron, thanks for your post. There are two issues here:
the AJAX create table dialog
the ENUM/SET editor
and they should be discussed separately.
About 1, I am wondering if AJAXification was an advantage here. See also the discussion on 2011-04-08 "Issues with AJAX" on this list. I suggested a mechanism to hide most form fields by default.
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
I'm not sure that we can span a dialog over the other frame.
... but at least the dialog could span the main frame.
Yea, such feature will probably only work after framesets have been removed, which should be done in the not so far future, I think
Do you suggest this removal for 3.5? I don't think that this has been agreed to (at least for 3.5).
Probably not for 3.5. Maybe it could be part of a project for gsoc next year? Part of a code cleanup project, or something.
Seeing more and more places in the code that could use improvement I am getting really fond of this idea. I think it would be very much worth considering to list a 'code cleanup' project in the gsoc 2012 project ideas.
Two more refactoring suggestions I have for this:
- For the theming I would build a default style that is always included containing all rather style independent configuration. Then let themes just overload those settings. That would make it way easier to build new themes. And save a lot copying.
- Replace all current 167 icon images with one css sprite file (using a generator like this: http://spritegen.website-performance.org/ ), and name them for what they symbolize. E.g.: b_key.png instead of b_primary.png. This way they can be reused in other places of pma without confusing file names).
Using CSS to display icons instead of using <img> also allows better theming (and puts style related stuff where it belongs to).
Besides, the idea of the navigation frame is to have a reference spot that is always available.
Why would someone need the navigation frame to be visible when a dialog is open? If he needs to navigate away, a click on the ESC button and he can do so again. The gain from having more space would be greater than the inconvenience of not seeing the navigation frame, I think.
Your argument makes sense.
-- Marc Delisle http://infomarc.info
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Wed, Jul 6, 2011 at 11:54 AM, Tyron Madlener tyronx@gmail.com wrote:
On Sat, Jun 25, 2011 at 6:26 PM, Tyron Madlener tyronx@gmail.com wrote:
On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-06-25 11:11, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 4:07 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:56, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote: > Le 2011-06-25 08:07, Tyron Madlener a écrit : >> I apologize for my directness but the newly implemented 'Create table' >> Dialog has an awful usability. > > Tyron, > thanks for your post. There are two issues here: > > 1. the AJAX create table dialog > > 2. the ENUM/SET editor > > and they should be discussed separately. > > About 1, I am wondering if AJAXification was an advantage here. See also > the discussion on 2011-04-08 "Issues with AJAX" on this list. I > suggested a mechanism to hide most form fields by default. >
Thanks, I've read through the conversation. I would agree on hiding rarely used fields like "Browser transformation,Transformation options,MIME type" but otherwise such feature in my opinion would only decrease usability. Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
I don't think an ajax dialog for 'create table' is inherently worse. It could actually be significantly better if for example the dialog could span over the left frame as well, giving more editing space than the old style create table page.
I'm not sure that we can span a dialog over the other frame.
... but at least the dialog could span the main frame.
Yea, such feature will probably only work after framesets have been removed, which should be done in the not so far future, I think
Do you suggest this removal for 3.5? I don't think that this has been agreed to (at least for 3.5).
Probably not for 3.5. Maybe it could be part of a project for gsoc next year? Part of a code cleanup project, or something.
Seeing more and more places in the code that could use improvement I am getting really fond of this idea. I think it would be very much worth considering to list a 'code cleanup' project in the gsoc 2012 project ideas.
Two more refactoring suggestions I have for this:
- For the theming I would build a default style that is always
included containing all rather style independent configuration. Then let themes just overload those settings. That would make it way easier to build new themes. And save a lot copying.
- Replace all current 167 icon images with one css sprite file (using
a generator like this: http://spritegen.website-performance.org/ ), and name them for what they symbolize. E.g.: b_key.png instead of b_primary.png. This way they can be reused in other places of pma without confusing file names).
Using CSS to display icons instead of using <img> also allows better theming (and puts style related stuff where it belongs to).
One more idea:
- Clean up pmahomme css code. I bet a good part of the css could be eliminated with generalization. (e.g. using <div class="smallFont"> instead of <div id="serverPageWithSmallfont">)
Besides, the idea of the navigation frame is to have a reference spot that is always available.
Why would someone need the navigation frame to be visible when a dialog is open? If he needs to navigate away, a click on the ESC button and he can do so again. The gain from having more space would be greater than the inconvenience of not seeing the navigation frame, I think.
Your argument makes sense.
-- Marc Delisle http://infomarc.info
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Thu, Jul 7, 2011 at 12:00 PM, Tyron Madlener tyronx@gmail.com wrote:
On Wed, Jul 6, 2011 at 11:54 AM, Tyron Madlener tyronx@gmail.com wrote:
On Sat, Jun 25, 2011 at 6:26 PM, Tyron Madlener tyronx@gmail.com wrote:
On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-06-25 11:11, Tyron Madlener a écrit :
On Sat, Jun 25, 2011 at 4:07 PM, Marc Delislemarc@infomarc.info wrote:
Le 2011-06-25 08:56, Tyron Madlener a écrit : > On Sat, Jun 25, 2011 at 2:29 PM, Marc Delislemarc@infomarc.info wrote: >> Le 2011-06-25 08:07, Tyron Madlener a écrit : >>> I apologize for my directness but the newly implemented 'Create table' >>> Dialog has an awful usability. >> >> Tyron, >> thanks for your post. There are two issues here: >> >> 1. the AJAX create table dialog >> >> 2. the ENUM/SET editor >> >> and they should be discussed separately. >> >> About 1, I am wondering if AJAXification was an advantage here. See also >> the discussion on 2011-04-08 "Issues with AJAX" on this list. I >> suggested a mechanism to hide most form fields by default. >> > > Thanks, I've read through the conversation. I would agree on hiding > rarely used fields like "Browser transformation,Transformation > options,MIME type" but otherwise such feature in my opinion would only > decrease usability. > Hiding most form fields maybe fixes the problem, but it doesn't fix the cause.
One cause is the number of form fields for each column, and the small work area of the dialog increases this space problem.
> > I don't think an ajax dialog for 'create table' is inherently worse. > It could actually be significantly better if for example the dialog > could span over the left frame as well, giving more editing space than > the old style create table page.
I'm not sure that we can span a dialog over the other frame.
... but at least the dialog could span the main frame.
Yea, such feature will probably only work after framesets have been removed, which should be done in the not so far future, I think
Do you suggest this removal for 3.5? I don't think that this has been agreed to (at least for 3.5).
Probably not for 3.5. Maybe it could be part of a project for gsoc next year? Part of a code cleanup project, or something.
Seeing more and more places in the code that could use improvement I am getting really fond of this idea. I think it would be very much worth considering to list a 'code cleanup' project in the gsoc 2012 project ideas.
Two more refactoring suggestions I have for this:
- For the theming I would build a default style that is always
included containing all rather style independent configuration. Then let themes just overload those settings. That would make it way easier to build new themes. And save a lot copying.
- Replace all current 167 icon images with one css sprite file (using
a generator like this: http://spritegen.website-performance.org/ ), and name them for what they symbolize. E.g.: b_key.png instead of b_primary.png. This way they can be reused in other places of pma without confusing file names).
Using CSS to display icons instead of using <img> also allows better theming (and puts style related stuff where it belongs to).
One more idea:
- Clean up pmahomme css code. I bet a good part of the css could be
eliminated with generalization. (e.g. using <div class="smallFont"> instead of <div id="serverPageWithSmallfont">)
Sorry for the spam but, one thing that would be really helpful is to have a CSS guide on the wiki, so students/developers know how to avoid duplicate css.
As for me, I just keep adding stuff to the css files because I absolutely no overview over the ~2700 lines of css code there :(
Besides, the idea of the navigation frame is to have a reference spot that is always available.
Why would someone need the navigation frame to be visible when a dialog is open? If he needs to navigate away, a click on the ESC button and he can do so again. The gain from having more space would be greater than the inconvenience of not seeing the navigation frame, I think.
Your argument makes sense.
-- Marc Delisle http://infomarc.info
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Sat, 25 Jun 2011 14:07:56 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
I don't know if its just me, but I see so many things gone wrong with this dialog.
Yes, it is. See also recent thread ("Is vertical mode useful?"), where I've posted several ideas how to improve create table dialog.
Some things I would change globally (taking the create table dialog as example) :
- Decrease the massive amounts of padding/margin of the jquery ui dialogs.
- I don't need a 40 pixel high title telling me that I'm currently
creating a table.
- Did you notice that there's is a 900 x 60 pixel (!) area that
only performs a single function: Containing the cancel button. This should be either drastically reduced in size or removed altogether (and put the cancel button inside the content)
It should also contain the submit button, but unfortunately it is not the case for most dialogs. This way you need to scroll down to be able to submit the form.
- Decrease those massive margins and paddings around input fields.
Those should be made big only where it actually improves the usability/readability. I would reduce the margin/padding from 6/4 to 2/2
I always found AJAX dialog having too small space for real content, but never found time to look at it.
And for the create table dialog:
- Display always in horizontal mode! Hardly any tables contain just 2 columns.
I agree.
- Start always with 4 fields
Makes sense (especially when any empty fields are ignored).
- Bug: You can actually open the dialog several times, cause the
enum/set editor to be in the background
Clearly a bug.
- Make all selects and text inputs way shorter. I'd reduce them by
~30% (selects as well!). The length/value field I would reduce by 50-70% or so.
You would not see ENUM/SET values in the short field...
- The null and A_I checkbox waste big amounts of space. I would put
them together in the form of " [ ] Null [ ] A_I " in a column called "Options"
I think column called NULL and A_I is more readable (again, see Adminer for how it looks).
- Remove the "Table name:" title, instead put 'Table name' into the
input field that disappears once the user focuses it
I don't think horizontal space would be a problem here, so I'd prefer to keep the title on single line with input box.
- Instead of "Add x tables [Go]" which does it's own ajax request I
would place a link "Add column" that adds one single column, but therefore adds it immediately (no ajax here!), allowing users to just spam click the link if they need a lot. Or alternatively use a select list that contains the numbers from 1 to 10 which adds columns immediately on the onchange event.
Definitely good idea. The original code is there from times we used almost none javascript and it's just wrapped by AJAX now.
- Display the input field for the default value only after "As
defined:" is selected, and also focus it automatically once its selected so the user can type immediately
Makes sense.
- Why do we have these footnotes at the bottom of the dialog when we
got PMA_showHint()? (Forgot to initialize them in js?)
Again, looks like a bug.
- For all the form fields below the columns: Remove all the gradient
backgrounds on the titles. What are they there for?
Probably caused by theming something else, in original theme this looks more consistent.
- In whatever way, put the Save and Cancel button side by side
Yes.
- The enum/set editor I find so bad, I don't even know how you could
improve that:
- If my table would be having 3 enums, I get 3 times this sentenced
thrown onto my screen causing the columns table to get even bigger.
- The dialog itself has a completely different style than everything
else in PMA and really badly implemented. Just some bugs: - Values for column "" - wheres the column name? - Why is "Go" a button and "Cancel" a link? - Single quotes are not escaped (put a ' into the value field) - Breaks if a user accidently enters a space - The background is grayed out, yet you can still interact with it (e.g. select text) - You can actually scroll away the content of the dialog by selecting text downwards - Visual bug: One can see all input fields disappear if you press ok/cancel
- Why not just a simple textfield where you let the user write one
value per line? I would build the enum/set like this: - if set/enum is selected and the user focuses on the input field, pop out a bigger textarea (that is placed like a datepicker) - let the user write one element per line - extend the textarea row height with every line written so the user doesn't have to scroll. (up to a certain limit of course, like 15-20 lines - also it should not force the to scroll the page) - with every line written or on lost focus, automatically parse the text and update the value field correctly formatted
Again, this looks like what Adminer does :-).