About MoodBar/Design#User_Experience_.28Feedback.29: I suggest to replace adjectives with nouns, which seem easier to localise and are more gender-neutral. "$PROJECTNAME made me feel...", "Share your mood", "My current mood is", "What does this make you feel?" (GetSatisfaction uses "How does this make you feel?") are some possibilities (answer: happiness/joy/whatever, sadness/depression/etc., confusion etc.). I think this will make especially romance languages (not only Italian) translators and users more happy, but should be useful for everyone.
Talk:MoodBar/Design
Actually, i already tried to do this in the Hebrew translation by writing something like "Editing Wikipedia caused me happiness/sadness/confusion". But this trick doesn't work for all messages in all languages. How about languages where "me" has gender, for example? I heard that it has gender in Thai, and maybe in many others.
Well, it looks definitely less common, though: can even "your", "my" or "you" (in the examples) have gender? You could drop that part too, anyway (in the translation), and leave just "current mood": it's obviously yours, you can't be asked the mood of someone else.
Of course "your" and "you" can have gender. They do in Hebrew and Arabic. In the Hebrew Wikipedia we deal with it by using plural most of the time, which is kinda gender-neutral, but it's still very ugly and everybody hates it.
Dropping "you" altogether is not quite natural either:
- "Mood".
- "Huh? Whose mood?"
I think we're blocked on this until we have GENDER and PLURAL available in Javascript.
Amir, and "my"? Those were just example, can't we find something? :-/ Anyway, link: bugzilla:30071.
Using {{PROJECTNAME}} is also a pretty bad idea, since we need {{GRAMMAR}} for this, and it seems it is not working in JavaScript. See also Localisation#Avoid_SITENAME. Maybe a whole string should be configurable in LocalSettings or something? « Saper // talk » 03:05, 1 March 2012 (UTC)
The comment field in the mockups appears to be smaller until it's required to be larger, and this would appear to be done automatically. I think that since the message is limited to a fixed length of characters, the initial and only size of the textarea should accomodate that amount of text (on average, since typing 140 "W"s takes more space than 140 "i"s using a variable width font). Twitter initially collapses their textarea (presumably to conserve screen space) but enlarges it on focus. Identica present the user with a textbox that is initially large enough to fit an average 140 character message, and it does not resize at all. Initially presenting the user with a textbox that can handle 3 to 4 rows of text also sets the users's initial expectation of how long the message is allowed to be - encouraging them to be more verbose, which hopefully translates into more specific and descriptive.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
You know, the use of an auto-sizing text box there is pretty much an artifact of having a text box construct pre-made so yeah, it should probably be locked at a specific size. Having it start small and enlarge on focus may be interesting but it's still a very small amount of text and screen real estate so I'm not sure what benefit would be gained by that (I normally dislike having things move around on the screen when it's unexpected).
I'm far more concerned with the character count tool not being implemented. That's a much bigger problem than the text field size.
Once a user has selected an emotion, are they allowed to change their selection? Direct manipulation interfaces such as this benefit greatly from allowing users to explore the features, so if not, I would recommend that they should be.
If indeed they should be, the gray and flat state of the emoticons that were not selected makes them look disabled. This would indicate to the user that their decision is final. Flattening a control's is commonly an indication of it being disabled. Additionally fading a control out (in this case lightening it) also is common in indicating it is disabled.
I would recommend not changing the non-selected emoticons, and providing a more distinctive selected state to compensate for the loss in contrast. Since color is a fairly short visual variable, something like size may be useful - such that the selected emoticon would appear larger when selected. You could also use an additional graphical element such as an outline to modify the shape of the selected item - shape is infinitely long visual variable so it's a good fit here.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
The user can, indeed, change their mind.
I'm not so concerned about this, to be honest. Of course, when playing with the tool, it all seems obvious to me but then I designed the thing.
Size changing is an interesting idea, though. I had explored using shapes to indicate selection but it ran into the "White Smiley on a Dark Background" problem so aborted exploration into that area.
Moodbar is still def. a work in progress. If we ever get resources devoted to it again, this might be something to play with.
Though, if we revisit anything, I'd prefer to come up with a simple icon that can be resized to 16x16, monochrome, that we can use to indicate a "Moodbar active" element. This falls into a plan to attach "mood" to specific items (like warning templates, or tools, or whatever) so we can track attitude towards unique targets rather than "overall impressions."
Just some nitpicks on the popup itself:
- The callout has an acute angle on the left side which is distracting, a symmetrical callout would look cleaner
- The callout is a little larger than seems necessary
- The popup has a horizontally biased border radius (is this on purpose?)
- The border radius on the popup doesn't mesh well with other graphical elements in the MediaWiki UI, or with the tool itself
- The popup has too small of margins given it's large border radius - they are probably fine with a smaller border radius
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
Ohman you have no idea how much I agonized and played with the angle of the the callout "pokey". I spent way too much time in the weeds on that. I even downloaded a whole pack of "Speech Bubble" shapes before I gave up and made my own by hand.
In the end, the choice was to make it as "comic book speech bubbly" as possible without being egregious so as to connect with existing "Speech Bubble" nomenclature.
The bias in the radius is because forms are naturally horizontal. Too much of a true "bubble" and we'd have crazy margins in some places while none in others.
I left the margins at 10px (I think they're 10; I'd have to get the source out) because I actually figured that increasing them to something larger would cause too many comments about "wasted space".
The size of the progress spinner and check or exclamation icons displayed to the user while sending data and after success or errors occur appear disproportionately large given the size and spacing of the tool. I would suggest sizing these icons down to about the same size as the emoticons on the previous screen.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
Yeah, these are probably too big. I sized them down much smaller in the Feedback Dashboard; we should switch to that.
I'm aware of the Firefox Feedback Addon's use of colored emoticons to emphasize emotions, coding it with color in addition to shape, but I think those are actually a bad design that shouldn't be repeated. To the credit of the MoodBar design, at least it used more mute tones so that black could feasibly used for facial features - the white facial features Firefox used make the emoticons appear non-human. Unfortunately, using the more mute colors causes them to be closer to Caucasian skin tones, making them appear to be more litteral than figurative colors being applied to a human. Colored skin tones such as these are seen in cartoon art, where the most conventional meanings aren't quite what is intended to be conveyed here - specifically green suggests poor health and red suggest anger. Perhaps we could consider using more common emoticon artwork, such as tango icons which use a yellow skin-tone that's vivid enough to be of nondescript race, but also light enough to allow black to be used for facial features, ensuring the emotes look human. Obviously this set does not include a confused icon, but one could be built from the available SVG files and following the Tango style guidelines.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
I actually drew most of the decisions about the icons themselves from Get Satisfaction rather than Mozilla; you're absolutely correct that the "white line" versions (Mozilla's) don't look very appealing.
I'm going to disagree with the assertion that "Green means Unwell". Clearly, there is the "Mr. Yuk" problem, but there we have color combined with facial expressions (as we do here). Since green is typically associated with fertility and forwardness, and red is associated with stress, I don't think that the colors are poor choices.
Regarding Tango: I am of the opinion that we should radically deprecate our use of the icon set and focus on our own style. The Tango research is of some value, but the icons themselves leave. . . a great deal to be desired <snark>(they look right at home in Windows 2000)</snark>. I'm not sure that their emoticons (the yellows) does anything "better" towards avoiding "caucasian-ness" - in fact, it probably works more towards that since they're "Simpsons Colored" (and in the Simpsons' world, "yellow" = "caucasian").
Since the feature is not designed or intended to facilitate bug reporting, it may be a good idea to provide a link to either bugzilla.wikimedia.org or a page (if one exists) which describes how to report a bug (such as w:en:Help:Report_bug on English Wikipedia). This should be carefully weighed against the cost of adding complexity to the user interface. If bug reports through the tool when this feature is not present prove to be rare, that may also suggest that this feature would detract from the simplicity of the tool without providing enough value to justify it's presence.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
As a follow up, Howie indicated that it's pretty rare that people report bugs through the tool so far, so it's likely that this isn't justified, but it may be revisited if it ever becomes common.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
The 'what is this thing' or whatever it is header does nothing to indicate that there might also be options under it, and since the one to disable the thing is there, it might be kind of useful to make tbe wordering more intuitive that expanding that part would be necessary to disable the thing, especially since pretty much nothing else on these wikis works like that.
If this is the wrong place to whinge about that, I apologise.
There are no older topics