On Thu, Feb 10, 2011 at 6:36 PM, Thibaut DEVERAUX < [email protected]> wrote:
> Code is very long... I see it now. Difficult to deal with half cutted code > lines so the full option makes sense... > > Of course, this is a problem for select boxes and buttons. User need to > make > a bigger effort to look what is linked to what. > I also don't like selects taking 100% width, especially for a Yes / No :) Otherwise 100% looks good. Jerome. > Having buttons/select at half and and boxes full may not help neither to > see > where are the buttons, because there may be no coherence of where to watch. > Well, this could be tested however, to be sure it is a real problem and not > a theorical one. > > I have to correct my vote. Even if I'd like to see the half/half solution I > feel like full is the best solution taking in account the long code > constraint. > > Thanks > > 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 Marius Dumitru Florea <[email protected]> > > > 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/VerticalFormsand > > >> 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 > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
