[Phpmyadmin-devel] Create table dialog

[Tyron Madlener]

On Thu, Jul 7, 2011 at 12:00 PM, Tyron Madlener <tyronx at gmail.com> wrote:
> On Wed, Jul 6, 2011 at 11:54 AM, Tyron Madlener <tyronx at gmail.com> wrote:
>> On Sat, Jun 25, 2011 at 6:26 PM, Tyron Madlener <tyronx at gmail.com> wrote:
>>> On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle <marc at infomarc.info> wrote:
>>>> Le 2011-06-25 11:11, Tyron Madlener a écrit :
>>>>> On Sat, Jun 25, 2011 at 4:07 PM, Marc Delisle<marc at infomarc.info>  wrote:
>>>>>> Le 2011-06-25 08:56, Tyron Madlener a écrit :
>>>>>>> On Sat, Jun 25, 2011 at 2:29 PM, Marc Delisle<marc at 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 at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>>>>
>>>
>>
>