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.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 (where items are auto-completed and visually added as items and not just text).This.
- 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.
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.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.
- 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
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?
On Fri, Oct 4, 2013 at 8:32 AM, Yuvi Panda <email@example.com> wrote:
On Tue, Oct 1, 2013 at 4:02 PM, Prateek Saxena <firstname.lastname@example.org> wrote:
> 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 -
> Design mailing list
Yuvi Panda T
Design mailing list
Pau GinerInteraction DesignerWikimedia Foundation
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list