Hi again,
On Wed, Feb 9, 2011 at 5:39 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Feb 9, 2011, at 4:32 PM, Raluca Stavro wrote:
Hello,
On Wed, Feb 9, 2011 at 5:01 PM, Vincent Massol <vincent(a)massol.net>
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
>> thibaut.deveraux(a)gmail.com
>>
http://www.thib-d.com
>> Skype : thibaut.deveraux
>>
>> @ Bricks, design et accompagnement projet
>> t.deveraux(a)bricks-studio.com
>> 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) <valicac(a)gmail.com>
>>
>>> On Wed, Feb 9, 2011 at 14:25, Marius Dumitru Florea <
>>> mariusdumitru.florea(a)xwiki.com> 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/ReleaseNotesXWikiEnterpris…
>>>> ).
>>>>>
>>>>> 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/AdministrationFormsfu…
>>>>> 2) *Full Width*:
>>>>>
>>>>
>>>
>
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
>>>>
>>>> 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/AdministrationFormsfu…
>>>
>>>
>
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
>>>
>>> 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/AdministrationFormsfu…
>>>>> higher resolution:
>>>>>
>>>>
>>>
>
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
>>>>>
>>>>> *Vote*:
>>>>> You can use the poll made for this vote:
>>>>>
>>>>
>>>
>
http://incubator.myxwiki.org/xwiki/bin/view/Polls/AdministrationFormsfullwi…
>>>>> or if you don't have an
account on incubator, just reply to this
mail.
>>>>> Please cast you votes.
>>>>>
>>>>> Thanks,
>>>>> Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs