Hey,
I've recently been working on the Campaigns edit page with Yuvi. Its currently a textarea where you have to enter JSON to edit the event's attributes. We tried to convert it into a form (of sorts) to get the same data. I first made a wireframe - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit.png - and then applied the Agora style to it - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit-agora.png. I wasn't able to spend as much time with Agora and thus most margins and sizes might be off, but it gives an idea.
Ideas and feedback are welcome - https://www.mediawiki.org/wiki/User:Prtksxna/Wikimedia_Campaigns_Edit
Regards, Prateek
*bump*
On Tue, Oct 1, 2013 at 4:02 PM, Prateek Saxena prtksxna@gmail.com wrote:
Hey,
I've recently been working on the Campaigns edit page with Yuvi. Its currently a textarea where you have to enter JSON to edit the event's attributes. We tried to convert it into a form (of sorts) to get the same data. I first made a wireframe - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit.png - and then applied the Agora style to it - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit-agora.png. I wasn't able to spend as much time with Agora and thus most margins and sizes might be off, but it gives an idea.
Ideas and feedback are welcome - https://www.mediawiki.org/wiki/User:Prtksxna/Wikimedia_Campaigns_Edit
Regards, Prateek
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Good work, Prateek. Just some quick comments:
- *Facilitating input.* For adding categories it may be useful to provide more support than asking to write each category in a textarea line. Although the control can be presented as a text area, it would be helpful that it behaves like the recipient list of many appshttp://i.imgur.com/6agolDj.jpg(where items are auto-completed and visually added as items and not just text). - *Reducing complexity.* The UI shows all sections at the same level of prominence. If some parts are less likely to be modified (or you can provide good default values) you can make those more compact. Some examples (you need to evaluate the right prominence level according to the real/expected use): - If it is uncommon to provide the tutorial info, that part of the form can be replaced by a "Add tutorial" link that reveals the form part once it is clicked. - Fields asking for user input can be presented in a more compact way while they are not being edited, becoming expanded once the user is editing them. - *Clarity.* For some fields the placeholder is "WikiText". Although that clarifies that you can use rich formatted text, it provides no information on the purpose of the field. If it is a description it should indicate that it is a description, and it may additionally inform that wikitext is allowed.
Hope this helps
Pau
On Fri, Oct 4, 2013 at 8:32 AM, Yuvi Panda yuvipanda@gmail.com wrote:
*bump*
On Tue, Oct 1, 2013 at 4:02 PM, Prateek Saxena prtksxna@gmail.com wrote:
Hey,
I've recently been working on the Campaigns edit page with Yuvi. Its currently a textarea where you have to enter JSON to edit the event's attributes. We tried to convert it into a form (of sorts) to get the same data. I first made a wireframe - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit.png - and then applied the Agora style to it - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit-agora.png. I wasn't able to spend as much time with Agora and thus most margins and sizes might be off, but it gives an idea.
Ideas and feedback are welcome - https://www.mediawiki.org/wiki/User:Prtksxna/Wikimedia_Campaigns_Edit
Regards, Prateek
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Yuvi Panda T http://yuvi.in/blog
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 04/10/13 08:44, Pau Giner wrote:
Good work, Prateek. Just some quick comments:
- *Facilitating input.* For adding categories it may be useful to provide more support than asking to write each category in a textarea line. Although the control can be presented as a text area, it would be helpful that it behaves like the recipient list of many apps http://i.imgur.com/6agolDj.jpg (where items are auto-completed and visually added as items and not just text).
Calling in HotCat (or mimicking its behaviour, since at its base it's pretty simple) for that would probably be a good idea, since that's the interface most Commoners will be used to using anyway.
- *Reducing complexity.* The UI shows all sections at the same level of prominence. If some parts are less likely to be modified (or you can provide good default values) you can make those more compact. Some examples (you need to evaluate the right prominence level according to the real/expected use): o If it is uncommon to provide the tutorial info, that part of the form can be replaced by a "Add tutorial" link that reveals the form part once it is clicked. o Fields asking for user input can be presented in a more compact way while they are not being edited, becoming expanded once the user is editing them.
This.
There should probably be two differentways the form is handled, though - one for campaign creation, which would emphasises the most importent sections and perhaps collapse less important/less commonly used ones, and one for editing an existing one, which would probably have all the used sections displayed outright, with unused collapsed so that they can either be ignored or added as needed.
- *Clarity.* For some fields the placeholder is "WikiText". Although that clarifies that you can use rich formatted text, it provides no information on the purpose of the field. If it is a description it should indicate that it is a description, and it may additionally inform that wikitext is allowed.
Hope this helps
Pau
I'd suggest not using placeholders at all for most of them beyond maybe things like 'wikitext supported' - placeholders disappear when the user starts typing, and most of this stuff will still be relevant after they've already entered something, especially on a complex form such as this. You'll also definitely want the input labels to be labels (as in outside the textareas/inputs) since otherwise when someone goes to edit an existing campaign they'll have no idea what each field actually is.
Another thing that I noticed was the on/off mechanism. This actually confused me at first, since what I'm used to for that kind of thing is just a checkbox, which is a more immediately clear affordance that folks tend to be used to anyway from other forms.
Nitpicking done, I too hope this helps. Now maybe YuviPanda can unlock these manacles?
-I
On Fri, Oct 4, 2013 at 8:32 AM, Yuvi Panda <yuvipanda@gmail.com mailto:yuvipanda@gmail.com> wrote:
*bump* On Tue, Oct 1, 2013 at 4:02 PM, Prateek Saxena <prtksxna@gmail.com <mailto:prtksxna@gmail.com>> wrote: > Hey, > > I've recently been working on the Campaigns edit page with Yuvi. Its > currently a textarea where you have to enter JSON to edit the event's > attributes. We tried to convert it into a form (of sorts) to get the > same data. I first made a wireframe - > https://www.mediawiki.org/wiki/File:Wm-campaigns-edit.png - and then > applied the Agora style to it - > https://www.mediawiki.org/wiki/File:Wm-campaigns-edit-agora.png. I > wasn't able to spend as much time with Agora and thus most margins and > sizes might be off, but it gives an idea. > > Ideas and feedback are welcome - > https://www.mediawiki.org/wiki/User:Prtksxna/Wikimedia_Campaigns_Edit > > Regards, > Prateek > > _______________________________________________ > Design mailing list > Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/design -- Yuvi Panda T http://yuvi.in/blog _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Prateek,
Great work, I think everyone else covered most of the things I was going to mention. Just a few notes
- For adding duplicate fields, I'd suggest having the text links below the field it duplicates, not above. - Use check boxes and labels instead of toggle switches for this context - Don't use multiple primary CTA constructive buttons in one flow (Green button) the one in the middle could probably just be a text link - Automatically add ??? to each upload - The control for choosing the default license is a bit confusing, I'd iterate on this, or use a radio control - "Fields asking for user input" is really confusing Is this how it will look (layout wise) to the end user? if not you might try rearranging the configuration screen so it looks closer to the presentation shown once configured. Both as a user and as someone configuring the interface I'd be at a loss when i got to that section.
All in all I think this will be a usability improvement for users, definately keep iterating on it a bit.
As far as the use of Agora controls the posted spec was a starting point for my team but many things have changed, eventually this will make it into a new living spec, but we're not there yet. You can see where things are progressing here https://www.mediawiki.org/wiki/Flow_Portal/Design/Iteration_5 Once we can migrate project specific controls into the Mediawiki.ui framework it will be much easier for community and foundation developers to reuse these controls (rather than having to make thier own each time)
Jared
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Oct 4, 2013 at 10:05 AM, Isarra Yos zhorishna@gmail.com wrote:
On 04/10/13 08:44, Pau Giner wrote:
Good work, Prateek. Just some quick comments:
- *Facilitating input.* For adding categories it may be useful to
provide more support than asking to write each category in a textarea line. Although the control can be presented as a text area, it would be helpful that it behaves like the recipient list of many appshttp://i.imgur.com/6agolDj.jpg(where items are auto-completed and visually added as items and not just text).
Calling in HotCat (or mimicking its behaviour, since at its base it's pretty simple) for that would probably be a good idea, since that's the interface most Commoners will be used to using anyway.
- *Reducing complexity.* The UI shows all sections at the same level
of prominence. If some parts are less likely to be modified (or you can provide good default values) you can make those more compact. Some examples (you need to evaluate the right prominence level according to the real/expected use): - If it is uncommon to provide the tutorial info, that part of the form can be replaced by a "Add tutorial" link that reveals the form part once it is clicked. - Fields asking for user input can be presented in a more compact way while they are not being edited, becoming expanded once the user is editing them.
This.
There should probably be two differentways the form is handled, though - one for campaign creation, which would emphasises the most importent sections and perhaps collapse less important/less commonly used ones, and one for editing an existing one, which would probably have all the used sections displayed outright, with unused collapsed so that they can either be ignored or added as needed.
- *Clarity.* For some fields the placeholder is "WikiText". Althoughthat clarifies that you can use rich formatted text, it provides no information on the purpose of the field. If it is a description it should indicate that it is a description, and it may additionally inform that wikitext is allowed.
Hope this helps
Pau
I'd suggest not using placeholders at all for most of them beyond maybe things like 'wikitext supported' - placeholders disappear when the user starts typing, and most of this stuff will still be relevant after they've already entered something, especially on a complex form such as this. You'll also definitely want the input labels to be labels (as in outside the textareas/inputs) since otherwise when someone goes to edit an existing campaign they'll have no idea what each field actually is.
Another thing that I noticed was the on/off mechanism. This actually confused me at first, since what I'm used to for that kind of thing is just a checkbox, which is a more immediately clear affordance that folks tend to be used to anyway from other forms.
Nitpicking done, I too hope this helps. Now maybe YuviPanda can unlock these manacles?
-I
On Fri, Oct 4, 2013 at 8:32 AM, Yuvi Panda yuvipanda@gmail.com wrote:
*bump*
On Tue, Oct 1, 2013 at 4:02 PM, Prateek Saxena prtksxna@gmail.com wrote:
Hey,
I've recently been working on the Campaigns edit page with Yuvi. Its currently a textarea where you have to enter JSON to edit the event's attributes. We tried to convert it into a form (of sorts) to get the same data. I first made a wireframe - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit.png - and then applied the Agora style to it - https://www.mediawiki.org/wiki/File:Wm-campaigns-edit-agora.png. I wasn't able to spend as much time with Agora and thus most margins and sizes might be off, but it gives an idea.
Ideas and feedback are welcome - https://www.mediawiki.org/wiki/User:Prtksxna/Wikimedia_Campaigns_Edit
Regards, Prateek
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Yuvi Panda T http://yuvi.in/blog
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing listDesign@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Hey Guys,
Thank you so much for the feedback. I am sorry for the late reply, I was busy with client work. Yuvi and I did see some of the problems pointed out by you guys but ignored them for two reasons (1) Its better than editing a JSON and (2) I didn't have any time last two weeks.
I do have some time now and will iterate over the design based on your feedback. To sum it all up -
* Labels instead of Placeholder text (use placeholder text wisely, where required) * Collapsing and Expanding fieldsets based on their importance and frequency of use * Better copy to guide the user * Well thought of form-inputs for different kinds of data (expanding textareas, radio controls etc) * Slightly different forms to edit and create Campaigns (though this was only for edits) * Stop using the primary button twice (use text for "Add another field")
So, Yuvi and me will go over this and fix things and share another version soon. We might be working on the "Campaigns List" page first as Yuvi said it has higher priority.
Thanks again for the feedback :)
Regards, Prateek
Great, we look forward to seeing the next iteration.
* * * * *Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Oct 11, 2013 at 1:20 AM, Prateek Saxena prtksxna@gmail.com wrote:
Hey Guys,
Thank you so much for the feedback. I am sorry for the late reply, I was busy with client work. Yuvi and I did see some of the problems pointed out by you guys but ignored them for two reasons (1) Its better than editing a JSON and (2) I didn't have any time last two weeks.
I do have some time now and will iterate over the design based on your feedback. To sum it all up -
- Labels instead of Placeholder text (use placeholder text wisely,
where required)
- Collapsing and Expanding fieldsets based on their importance and
frequency of use
- Better copy to guide the user
- Well thought of form-inputs for different kinds of data (expanding
textareas, radio controls etc)
- Slightly different forms to edit and create Campaigns (though this
was only for edits)
- Stop using the primary button twice (use text for "Add another field")
So, Yuvi and me will go over this and fix things and share another version soon. We might be working on the "Campaigns List" page first as Yuvi said it has higher priority.
Thanks again for the feedback :)
Regards, Prateek
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design