Talk:StarRatings

Submitting
Shall I add a submit callback? --


 * Never mind. I just added it :) --

Update
I don't know how far you are or what you're doing, but I think my work is done. In terms of functionality $.fn.ratingWidget is complete. The only thing I still plan to modify is the horizontal whitespace. There should be a little more. It wouldn't hurt to make its amount configurable either.

It would also be neat to compile a small list of alternate images.

But other than that my work is done. Unless I hear something to the contrary from you, of course. --


 * Sorry, I've been busy with other stuff so progress is slow. The only thing I think may be a problem is that there's no status indicator or vote counter. When the AJAX happens, there's no visual feedback that it's working. I suppose, I could just add $x.startThrobbing to the interface wrapper. Lunarity 17:01, December 14, 2012 (UTC)


 * I think it would be nice if the stars themselves would perform the throbbing animation... (needs testing)... In any case I'll add a startThrobbing and a stopThrobbing event that you can trigger on the widget.


 * We haven't talked about how to present the data beyond the widget. Do we want to show the user's rating in textform in addition to the stars? And what else? The number of votes? The average? And how do we format it?


 * My personal preferences would be something like this:


 * The idea is to put the page layout into the end-user's hands. They can move the items around on the page however they like, make them smaller, larger, bold and whatnot. The items should also be optional. If they don't particularly care for the, no problem, just leave it off the page.


 * Then we'd provide one or two presets for copypasting and leave the rest up to the users...


 * We should make the data available via JS as well though. Maybe as  properties of the   container...


 * Does that make sense to you? --


 * Conceptually I was treating the entire display as part of the widget since it's effectively a self-contained unit that displays everything, ala how a tab widget or the rating widget on merlin works. I don't really have much preference, I'm really just basing on what I've seen in existing ratings widgets. The most common data is a vote counter, and the current average of all votes in text form. These give an idea of how popular the page is and the current trend which make them the most useful.


 * I'm not sure about the detached vote display, it makes things rather more complicated for both us and users due to the potential flexibility of it [What does  do in that BTW?]. There's also localisation problems, it would be impossible to write "X votes" in that design for something like Polish, since Polish has 3 plural forms with a strange pattern. What I was thinking of was just slapping a span after the end and filling it using a configurable string printer.


 * The actual implementation of this isn't too bad, it's just a regex or two and a list of plural functions. The site CSS can then play with it to reposition the text however it wants. OTOH, we could blend approaches and have . This would work the same way as   from   and substitute the correct values in place, although this makes it harder to supply built-in defaults for the 99% of everyone who aren't going to create custom messages.


 * One thing that's nit-picky is the number of stars, some people like 5 but others like 10. Underneath, the core logic is identical either way but as an aesthetics thing, people tend to have irrational preferences for one or the other.


 * I'm not sure what exposing the inner state gets us, you're already exposing the current value via . I suppose I can export the full vote tally, though I don't know who'd consume it. That would also need an event that fires whenever the data changes as well.


 * One other thing I've been thinking about is that the widget on Merlin also has the Ⓘ button next to it which takes you to a statistics readout page. I've been pondering if it would be possible to do something like that, except popout a box like the reference popups instead of navigating to a new page. OTOH, I don't want to get too elaborate as more text means more i18n problems. Lunarity 22:35, December 14, 2012 (UTC)


 * I suppose I could add the option to show 10 stars instead of 5. It shouldn't be too hard to do. Then I would normalize the ratings to a 1 to 10 scale instead of a 0.5 to 5 scale. That's what your code expects anyway, isn't it?


 * The idea behind exposing the inner state is that users might want to use StarRatings like a library. But then again: If we design the wikitext interface flexible enough, we will remove that need entirely...


 * I don't really like stuffing all textual information into a printf of sorts. If only because as a designer I want the flexibility to position and otherwise style elements with as much granularity as possible.


 * It's true that it potentially makes things more complicated for the users, of course. That's why I suggested providing one or two presets they can simply copypaste and be done with it. The flexibility should only be for users who really ask for it.


 * Having a different target-element (that may or may not be present) for every data.value makes our code slightly more complicated too, but only slightly so. I don't think that would be a big deal, really.


 * The data-of attribute is for cases where users want to have more than one rating widget on the page. --

Here's a quick demo of what a complete widget plus outputs might look like:



And here are a few symbols I found on the internet:



They're all SVGs and they were all released under a Creative Commons license. I'll add them to a live preview soon... --


 * One thing I should note, I have no access to the user's vote. We know the vote when the user clicks the widget but the poll tag doesn't offer the past vote when the page is loaded so there's no way to tell what it was, or if they even voted at all.


 * How does integrating the text into the design like that work with the detached vote data spans? You need to position them rather precisely for that to work don't you? Also, the average is rarely exactly 1 or 0.5, can this display 3.69 as the average or is it rounding? [The initial state graphic display also doesn't seem to handle this either, that's also rounding to nearest 0.5] I'm also slightly concerned about the length, that design works for English and more compact languages like CJK but others have longer words that might not fit so neatly. Lunarity 21:21, December 15, 2012 (UTC)


 * "One thing I should note, I have no access to the user's vote. We know the vote when the user clicks the widget but the poll tag doesn't offer the past vote when the page is loaded so there's no way to tell what it was, or if they even voted at all."


 * Ouch. That's bad. That's really bad. Is there absolutely positively no workaround? --


 * Couldn't you check their vote from the element they click on? -- Kangaroopowah  ( Talk ) 23:19, December 15, 2012 (UTC)


 * No. Sadly not. The problem arises when the user returns to the page after having voted before. He hasn't clicked on anything yet - not this time around. Ideally the widget would display his earlier vote. Without that bit of information he might be tempted to vote again. Unfortunately the widget would then tell him that his vote was counted long ago and that he just took an action for naught. Personally I would find that rather annoying. The problem is essentially: We'd be putting the burden of remembering past interactions on the user. --


 * What about localStorage? -- Kangaroopowah  ( Talk ) 02:04, December 16, 2012 (UTC)