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