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/ReleaseNotesXWikiEnterprise...
). > > 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/AdministrationFormsful...
> 2) *Full Width*: >
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsful...
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/AdministrationFormsful...
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsful...
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/AdministrationFormsful...
> higher resolution: >
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsful...
> > *Vote*: > You can use the poll made for this vote: >
http://incubator.myxwiki.org/xwiki/bin/view/Polls/AdministrationFormsfullwid...
> 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