[xwiki-devs] [UX][Vote] New Administration forms width: partial or full
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... *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
Hi Caty, On Feb 9, 2011, at 11:21 AM, 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...
Big +1 for 2). Note that an example with the "Presentation" screen is even more telling since there are more textareas/string fields. Note that currently the partial width is not good since it's 50% and when you resize for a smaller screen it stays at 50% making fields harder and harder to read. I'm ok if we decide to go 100% for all controls except for select boxes.
*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.
Voted there too. Thanks -Vincent
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). 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
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, ** Partial ou Full ?* Partial ! Just imagin the full solution with a 1920px resolution... ... 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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. 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
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
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. 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
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
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. 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
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. 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/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
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/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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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. 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/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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/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/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/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
_______________________________________________ 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
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
Hi, On Wed, Feb 9, 2011 at 16:01, 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.
It's really a question of personal preference, I like "partial" better than "full" in the above examples. 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.
As Caty mentioned it, it would be better to change the input type to a textarea when appropriate. Guillaume
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
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
On Feb 9, 2011, at 5:58 PM, Guillaume Lerouge wrote:
Hi,
On Wed, Feb 9, 2011 at 16:01, 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.
It's really a question of personal preference, I like "partial" better than "full" in the above examples.
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.
As Caty mentioned it, it would be better to change the input type to a textarea when appropriate.
Doesn't solve anything, I still have half of my screen empty! -Vincent
Guillaume
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
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
On 02/09/2011 03:53 PM, Thibaut DEVERAUX wrote:
Hi,
** Partial ou Full ?*
Partial !
Just imagin the full solution with a 1920px resolution... ... Long lines, text on the right, button far on the left, on what am I clicking on already ?
But also imagine a modest 1366 screen like mine, with a cluttered form to the left (see look & feel -> presentation, it's a very good default example), in which I cannot read what's written because all the text is longer than the inputs in which is written, all these while I can see a superb empty, snowwhite, half of screen to the right of this form. I agree that long inputs can cause issues, but filling the space with potentially less useful stuff while the form stays cluttered to the left, just because we don't want to have inputs that scale in the whole page it also not that good. I know that it doesn't work on all browsers (or it's not really straightforward to), but we might want to put a max-width (and or min-width) to the inputs, around 800 or so, which is decent. I'm not a strong advocate of full, although on my screen (1366) and to my eye it looks very well. All I know is that we shouldn't have a form in which you cannot read anything with white space beside it. Thanks, Anca
** 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
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
On Wed, Feb 9, 2011 at 17:07, Anca Luca <[email protected]> wrote:
On 02/09/2011 03:53 PM, Thibaut DEVERAUX wrote:
Hi,
** Partial ou Full ?*
Partial !
Just imagin the full solution with a 1920px resolution... ... Long lines, text on the right, button far on the left, on what am I clicking on already ?
But also imagine a modest 1366 screen like mine, with a cluttered form to the left (see look & feel -> presentation, it's a very good default example), in which I cannot read what's written because all the text is longer than the inputs in which is written, all these while I can see a superb empty, snowwhite, half of screen to the right of this form.
I agree that long inputs can cause issues, but filling the space with potentially less useful stuff while the form stays cluttered to the left, just because we don't want to have inputs that scale in the whole page it also not that good.
I know that it doesn't work on all browsers (or it's not really straightforward to), but we might want to put a max-width (and or min-width) to the inputs, around 800 or so, which is decent.
I'm not a strong advocate of full, although on my screen (1366) and to my eye it looks very well. All I know is that we shouldn't have a form in which you cannot read anything with white space beside it.
I think the solution to this problem is: - have min-width: 450px; on controls (IE6 doesn't support this - that's life) - replace Presentation > Footer > "Copyright notice" and "Version" with textareas instead of inputs. When the content is too big to accommodate the control we select a better suited control. Thanks, Caty
Thanks, Anca
** 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
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
Hi, On Wed, Feb 9, 2011 at 5:26 PM, Ecaterina Moraru (Valica) <[email protected]
wrote:
On Wed, Feb 9, 2011 at 17:07, Anca Luca <[email protected]> wrote:
On 02/09/2011 03:53 PM, Thibaut DEVERAUX wrote:
Hi,
** Partial ou Full ?*
Partial !
Just imagin the full solution with a 1920px resolution... ... Long lines, text on the right, button far on the left, on what am I clicking on already ?
But also imagine a modest 1366 screen like mine, with a cluttered form to the left (see look & feel -> presentation, it's a very good default example), in which I cannot read what's written because all the text is longer than the inputs in which is written, all these while I can see a superb empty, snowwhite, half of screen to the right of this form.
I agree that long inputs can cause issues, but filling the space with potentially less useful stuff while the form stays cluttered to the left, just because we don't want to have inputs that scale in the whole page it also not that good.
I know that it doesn't work on all browsers (or it's not really straightforward to), but we might want to put a max-width (and or min-width) to the inputs, around 800 or so, which is decent.
I'm not a strong advocate of full, although on my screen (1366) and to my eye it looks very well. All I know is that we shouldn't have a form in which you cannot read anything with white space beside it.
I think the solution to this problem is: - have min-width: 450px; on controls (IE6 doesn't support this - that's life)
+1, yes partial width with a minimum width.
- replace Presentation > Footer > "Copyright notice" and "Version" with textareas instead of inputs. When the content is too big to accommodate the control we select a better suited control.
+1. An input being very wide is hard to read. It would be better to have the display less large and therefore on several lines using textarea. I am also big +1 for help (tooltips) on the right part that. You don't want to go read documentation everytime you want to change a configuration. That would greatly improve user experience. Makes a lot of sense to add help tips where you actually need those Thanks, Thibaut
Thanks, Caty
Thanks, Anca
** 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
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
participants (9)
-
Anca Luca -
Ecaterina Moraru (Valica) -
Guillaume Lerouge -
Jerome Velociter -
Marius Dumitru Florea -
Raluca Stavro -
Thibaut Camberlin -
Thibaut DEVERAUX -
Vincent Massol