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 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
On Fri, Oct 4, 2013 at 10:05 AM, Isarra Yos <zhorishna(a)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
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):
- 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". 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(a)gmail.com> wrote:
*bump*
On Tue, Oct 1, 2013 at 4:02 PM, Prateek Saxena <prtksxna(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design
--
Yuvi Panda T
http://yuvi.in/blog
_______________________________________________
Design mailing list
Design(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/design