On Feb 9, 2011, at 4:32 PM, Raluca Stavro wrote: > Hello, > > On Wed, Feb 9, 2011 at 5:01 PM, Vincent Massol <[email protected]> wrote: > >> >> On Feb 9, 2011, at 3:53 PM, Thibaut DEVERAUX wrote: >> >>> Hi, >>> >>> ** Partial ou Full ?* >>> >>> Partial ! >>> >>> Just imagin the full solution with a 1920px resolution... >> >> I am on 1920px and I can tell that the full width is nicer than the partial >> solution which doesn't even reach half of the screen making all text >> cluttered and not using the screen real estate. >> >> Partial: >> http://tinycoke.com/_6ripkVnWC9iA/partial.png >> >> Full: >> http://tinycoke.com/_6r6qg3AQJmy8I/full.png >> >> See how texts are nicer in full. >> >> As I said in my first response I wouldn't care if the select fields had a >> fixed sized based on the length of the inputs in them, but for Text and >> TextArea fields it's much nicer to take the full size. >> > > I would choose partial width + a way how to extend to full width and get > back to partial width. > It would be a button/link on the top right with a small JS script adding and > removing the 'half' class name that is used on the form. > By default it should be partial width. > This is kind of the same behavior of 'Maximize »' option used for textarea > fields inside object editor.
Interesting idea but I don't like it and for me it's not the same as with the Maximize button. Here we're talking about using **unused** space. The full screen solution is about changing the layout and removing stuff to maximize the view space. There's no reason whatsoever IMO to add a button just to fill empty white space that isn't used. Thanks -Vincent > Raluca. > > >> >> Thanks >> -Vincent >> >>> ... Long lines, text on the right, button far on the left, on what am I >>> clicking on already ? >>> >>> ** Having anotations on the left.* >>> >>> Nice idea. It helps a lot on such complicated things as the wiki >>> configuration. >>> If possible, each explanation could be on the front of the field it is >>> related to make it easier to read. >>> >>> Have a nice day >>> >>> Thibaut DEVERAUX >>> Tel : 06 75 51 20 80 >>> [email protected] >>> http://www.thib-d.com >>> Skype : thibaut.deveraux >>> >>> @ Bricks, design et accompagnement projet >>> [email protected] >>> Découvrir Bricks : bricks-studio.com >>> L'actualité du studio sur notre blog : bricks-it.com >>> Se renseigner sur le design : design-keys.org >>> >>> >>> >>> 2011/2/9 Ecaterina Moraru (Valica) <[email protected]> >>> >>>> On Wed, Feb 9, 2011 at 14:25, Marius Dumitru Florea < >>>> [email protected]> wrote: >>>> >>>>> Hi Caty, >>>>> >>>>> On 02/09/2011 12:21 PM, Ecaterina Moraru (Valica) wrote: >>>>>> Hi, >>>>>> >>>>>> Since XE 3.0M2 we have a new administration look ( >>>>>> >>>>> >>>> >> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise30M2 >>>>> ). >>>>>> >>>>>> There was a debate if the forms should be full width or not. >>>>>> >>>>>> *Variants*: >>>>>> 1) *Partial Width* (current): >>>>>> >>>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfullwidthornot/partialWidth.png >>>>>> 2) *Full Width*: >>>>>> >>>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfullwidthornot/fullWidth.png >>>>> >>>>> What's the benefit of enforcing the same width? I think I prefer the >>>>> width to depend on the size of the information displayed (for select >>>>> boxes) or expected to be entered (text input). For instance if I have a >>>>> text input for entering a small number I wouldn't like it to span the >>>>> entire page width. Same for a select box with options of small length >>>>> (e.g. Yes/No). >>>>> >>>>> >>>> Until the form standard, we had all kinds of sizes for text inputs, >>>> textareas, select boxes. This created a very messy/not standardized >>>> feeling. >>>> >>>> Test: remove "xform" class from <form class="xform half". Results: >>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfullwidthornot/noStandardGeneral.png >>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfullwidthornot/noStandardPresentation.png >>>> >>>> Having all controls the same width the form layout presents itself >>>> differently: it look compact, aligned and unitary. >>>> >>>> Beside the unitary look, you can have also some technical reasons. The >>>> other >>>> solution beside a 100% width for most of the controls, would have been >> to >>>> set some standardized sizes for each type of control. This sizes are >>>> already >>>> defined in "Size" column of the "Usage" category >>>> http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms and are >>>> recommended to be used on future forms (and also to be modified on the >> old >>>> forms - already done for some forms I revised). >>>> The problem with this approach is that this means that we should have >>>> changed all the existing code that contained forms elements in order for >>>> the >>>> forms to look unitary and standardized. >>>> Also, some browsers (like IE) don't render the same width for different >>>> controls even if you specify the same size (ex. <input type='text' >>>> size='60' >>>> will be longer than <input type='password' size='60' ). So this means >> again >>>> different widths, more frustration (obs. even with width 100% for all >>>> controls, <select> is still rendered shorter). >>>> >>>> From an usability point of view, the restricted cases where we should >>>> adjust >>>> the width of our form fields so it matches the length of the expected >> input >>>> are: credit card number (16 digits), credit card security code (4 >> digits), >>>> dates (2 digits + x + 4digits, but this case can be replaced with other >>>> solutions: date pickers, selects, etc). This are some of the cases where >> we >>>> know the exact size of the field and can act accordingly. Beside them, >>>> there >>>> are no rules and all is limited to what the developer/designer thinks >> fits >>>> the layout. We already have an exception for "Inline" layout forms ( >>>> http://platform.xwiki.org/xwiki/bin/view/DevGuide/InlineForms ) and we >> can >>>> make styles also for the cases mentioned above, but those cases are not >>>> encountered in XE standard distribution. >>>> >>>> Hope this answers the question, >>>> Caty >>>> >>>> >>>> >>>>> Thanks, >>>>> Marius >>>>> >>>>>> >>>>>> *Test*: You can test this "partial"/"full" width on your resolution by >>>>>> removing "half" class from "<form class='xform half"" definition. >>>>>> >>>>>> *Considerations*: >>>>>> - When voting please consider that the width will be set for small and >>>>> high >>>>>> resolutions (that until we will improve our skin to detect the >>>>> resolutions >>>>>> change). >>>>>> - You should consider how form controls look (readability, usability) >>>> on >>>>>> different sizes, like<select>, input, textarea, etc. >>>>>> >>>>>> *Other Solutions*: >>>>>> A. The problem is that on large resolution is hard to read the >> controls >>>>>> because the form are too wide - on small resolution there is unused >>>>> space. A >>>>>> solution would be to use CSS media queries and adjust the width for >>>>> smaller >>>>>> resolutions. >>>>>> B. Another solution would be to use the additional space given by the >>>>>> partial width and provide some extra help for the sections, see >>>>>> smaller resolution: >>>>>> >>>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfullwidthornot/annotationSmall.png >>>>>> higher resolution: >>>>>> >>>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfullwidthornot/annotationLarge.png >>>>>> >>>>>> *Vote*: >>>>>> You can use the poll made for this vote: >>>>>> >>>>> >>>> >> http://incubator.myxwiki.org/xwiki/bin/view/Polls/AdministrationFormsfullwidthornot >>>>>> or if you don't have an account on incubator, just reply to this mail. >>>>>> Please cast you votes. >>>>>> >>>>>> Thanks, >>>>>> Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
