Hi again, On Wed, Feb 9, 2011 at 5:39 PM, Vincent Massol <[email protected]> wrote:
> > 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. > I agree that JS is not the best solution and I just wanted to find a workaround for those who prefer 100% width. I really think that full width is way too much. Indeed, filling empty spaces is a good practice, but that doesn't mean that we should exaggerate with this rule. When I look at the current version of partial width, I am able to easily browse through the form elements. On looking to your version of full width, I am lost between long elements like <input> and <select>. I can't easily see the labels and I can't easily distinguish between categories because my eyes tend to concentrate on the horizontal space. I agree that having larger <textarea> and <input> fields would help the user to work better with their content. But this doesn't mean that we should drop readability. I also agree with Anca about min-width, but I think that max-width is not needed. As Caty said, maybe we should switch from <input> to <textarea> for a list of fields that usually can contain a lot of characters (as long as we keep backward compatibility). I stick to the partial width solution ;) Raluca. > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
