On 02/09/2011 06:17 PM, Ecaterina Moraru (Valica) wrote: > On Wed, Feb 9, 2011 at 17:39, 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 wouldn't add JS script to switch between modes. Is not a matter of choice, > but a matter of standard. >
> IMO is not about having "unused space". For me, if we make the forms full > width, the "unused space" will be still unused, but will be placed inside > the forms instead of outside. Having the forms 1000px wide doesn't provide > me any advantage over having them 400px. The inputs need to be big enough to > enter the right amount of information in them. That's why the only problem > with "partial" width is when the screen is smaller, the forms are not big > enough. This is the only case I would make the input bigger (have min-width > : 350px; for example). > > On the other hand, on wide screens, having the forms 100% is too much. > First of all is bad readability. For me, I just see lines and is hard to > distinguish the inputs from the background. My eyes need to scan the whole > area in order to determine its boundaries. > Then is about control type: the difference between input and select. The > user will have to scan 1000px to get to see if the select has the drop-down > arrow or is just an input field. I fully agree with Caty on this. Thanks, Marius > > Also, I would you to imagine full width on forms like "Create Space", > "Create Page", "Copy Page", etc. > > Thanks, > Caty > > >> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
