10 Feb
2011
10 Feb
'11
6:43 p.m.
On Thu, Feb 10, 2011 at 6:36 PM, Thibaut DEVERAUX <
thibaut.deveraux(a)gmail.com> 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
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 Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
to
choice,
full
enough
to
The
am
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
inputs,
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
are
order
(
and
definition.
by
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
http://incubator.myxwiki.org/xwiki/bin/download/Polls/AdministrationFormsfu…
http://incubator.myxwiki.org/xwiki/bin/view/Polls/AdministrationFormsfullwi…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 02/09/2011 06:17 PM, Ecaterina Moraru (Valica)
wrote:
> On Wed, Feb 9, 2011 at 17:39, 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 >
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 but a matter of standard.
> IMO is not about having "unused space". For me, if we make the forms
> 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 to
big
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
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
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. 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
I
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…
>>>> 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 (
>>>>>>>
>>>>>>
>>>>>
>>>
>
>>>>>> ).
>>>>>>>
>>>>>>> There was a debate if the forms should be full width or not.
>>>>>>>
>>>>>>> *Variants*:
>>>>>>> 1) *Partial Width* (current):
>>>>>>>
>>>>>>
>>>>>
>>>
>
>>>>>>> 2) *Full Width*:
>>>>>>>
>>>>>>
>>>>>
>>>
>
>>>>>>
>>>>>> 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
>>>>>> textareas, select boxes.
This created a very messy/not
standardized
>>>>> feeling.
>>>>>
>>>>> Test: remove "xform" class from<form class="xform
half". Results:
>>>>>
>>>>>
>>>
>
>>>>>
>>>>>
>>>
>
>>>>>
>>>>> 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
>>>>> 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
>> 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 >> 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"" >>>>>>>>
>>>>>>>> *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 > the
>>>>>>> partial width and provide some extra help for the sections,
see
>>>>>>> smaller resolution:
>>>>>>>
>>>>>>
>>>>>
>>>
>
>>>>>>> higher resolution:
>>>>>>>
>>>>>>
>>>>>
>>>
>
>>>>>>>
>>>>>>> *Vote*:
>>>>>>> You can use the poll made for this vote:
>>>>>>>
>>>>>>
>>>>>
>>>
>
>>>>>> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs