Due to many other projects, and most importantly, new xScape theme framework, work on GDSR 2.0 is slower than I would have liked to. But, things are progressing, and keep reading if you are interested in the current status of major revision of GD Star Rating.
Due to current status of WordPress development and increasing popularity of BuddyPress plugin, many of the features of GDSR 2.0 will be targeting BP and new WP 3.0. First major change in plans is that plugin will not support current WPMU. And by that I mean ‘old’ versions including WPMU 2.9. WP 3.0 and it’s multi site feature will be supported including BuddyPress. Because of MU installation, and many requests, GDSR 2.0 will allow centralized settings on the site level and also settings on the blog level. With that in mind, database installation will be more flexible. You will be able to have only site wide database tables or mix of site level and blog level tables. At this moment I don’t know if WP before 3.0 will be supported at all.
Plugin is not going to be limited to post/page/comment ratings. Default installation will include several mod_types (as they are called right now): post, comment, user, category, link and all custom post types. This will allow expanding plugin to get new mod_types. For instance, you can expand it to have BuddyPress related types for rating groups.
Also, some things will be much simpler. You will have 3 rating types (standard star rating, multi star rating and thumb rating), and each of them can be used for all mod_types. Each mode type will be able to have own rating rules. Main settings panel will have only 10% (yes, 90% of options will be gone) of settings you have in current version. However, some of these settings will be moved to more logical locations. Database needs will be 50% smaller with much fewer tables and better organization. As for the rendering T2 templates will still be in use, but with fewer templates and with multi language templates installation. All default templates will be translated, and installed with the locale settings.
Stars and thumbs sets and CSS are completely changed (already done), with much simpler CSS, and only one image for the whole set and all the sizes. There will be settings allowing you to move CSS, JS files and images to different location (some CDN for example).
That’s it for now. We are still 2-3 months away, but trust me, I want to make this new version to be the best possible rating plugin. If you have some suggestion based on this post, please leave a comment.
loading...
Share this:
Comment Link
The move towards BuddyPress is an excellent idea – I have long thought that star ratings would bloom in that environment, and BuddyPress itself has come a long way in the past 6 months.
I know I’ve submitted this idea to you before but, as you have asked for suggestions, I’ll throw it into the mix:
It would be amazing if, within BuddyPress’ social context, users could vote each other’s post up and down, adding to an overall score, along the lines of the highly success programming knowledge exchange, StackOverflow. I believe that a GDSR that kept score would utterly transform the way people use BuddyPress, encouraging participation and making the sites much more “sticky”.
I have been playing around with the WP 3.0, it’s wonderful, particularly custom post types. Beta 1 will be released tomorrow and beta 2 will be next week.
loading...
Comment Link
I have your idea from before already on the planning list, and I believe that there are many benefits from integrating GDSR with BP. That’s why I will make a database model much different than it is right now, so that data would be more centralized and easier to use in such dynamic environments BP provides.
WP3 is good so far, I have been working with SVN trunk for some time now, but I think that releasing so soon is not a good idea. Original timeframe was unrealistic, and this on is not much better with a full month behind on initial plans. And releasing beta with 500 open TRAC tickets and beta 2 soon after is not good. In my opinion beta should be delayed for at least 2 more weeks, with final release end of may. I am afraid that release problems with both 2.8 and 2.9 are simply forgotten, and that this 3.0 is much more sensitive being major release and featuring so many new things. I hope that I am wrong about this.
loading...
Comment Link
I’m delighted my idea made it onto the list
I think that the “knowledge exchange” model could work particularly well in the context of something like your TV site – you could have groups around certain shows and users could ask questions such as “Why is Buffy acting so strange in this episode?” or “Why isn’t Anya in this show anymore?”, and the more knowledgeable members of the group can earn points by giving interesting answers.
Yes, I agree that they should take the time to get WP 3.0 right.
Even if WP 3.0 is rescheduled to the end of May, I don’t think you should waste your time or restrict your possibilities by making GDSR 2.0 compatible with older versions of WP.
Keep up the good work and let me know if you need any testing help.
loading...
Comment Link
Whenever WP3 is released, GDSR 2.0 is not going to be released before it, a lot of work needs to be done. And with such milestone release of WP, supporting old versions will cause too much problems. GDSR 2.0 developement will be under WP3, and I will test after that if it works with older versions.
I hope to release some alpha by the end of april.
loading...
Comment Link
I appreciate the “less is more” approach (e.g. economy of table size). I think (not just for GDSR but also for all of WP) that another thing to stay focused on is the response rate. I have no idea about particulars (haven’t done any significant amount of *REAL* programming in well over a decade), but my gut feeling is that if data structures can be simplified to the extent that a large portion of the database for operations could simply be transmitted to the local machine (refreshing once every X minutes) and then operations could be performed on the client side, then that might drastically increase response times — not only due to local processing but also due to less server side calculations. I know such an approach is perhaps regarded as “second rate” from the perspective of “less than real time”, but if it were possible to return results in 0.1 second instead of 2.0 seconds (not a real comparison, just “for example”), then I think I would be happier.
I realize this is quite abstract and not particular in any way — it’s just a general philosophy / approach idea.
Love the app so far!
loading...
Comment Link
“drastically increase response times” — i.e. drastically IMPROVE response times (which means it would actually REDUCE them
)
loading...
Comment Link
Current GDSR started as very simple plugin, but over time it grew (out of control one might say), and it’s time to do it right. Database model is too big, too many redundant things are stored. New model is more to the point, with many tables merged and compacted. I still don’t have actual code that will work with database, but I will write about it soon, but I expect that execution times will be much lower and overall response of plugin faster.
loading...
Comment Link
I didn’t mean that as a criticism — I’m just thinking about the general movement toward ever more + tinier bits of information in the real-time cloud… I’m thinking it’s a bit of overkill, and I think there should be a movement more towards rewarding the user with speed rather than too much attention with cloud-based computing (and associated database centralization + overloads … e.g. twitter fail whale, etc.).
Do you see what I mean? I think anything that can be done to get data onto the user’s machine + then do operations there will lead to a more stable environment.
Mind you (in case you haven’t noticed
): I am saying all of this without understanding whether it’s possible with today’s programming languages.
loading...
Comment Link
I understand, don’t worry, I wasn’t referring to you. When you use normal WP adding even 15 tables is not that big of a deal, but nowdays with MU installations and BP, if you have 100 blogs on the website, GDSR will potentially add 1500 tables, and that is too much. As I said, in the beginning scope of the plugin was small I was making it for myself only, and I wasn’t thinking that plugin will be so popular.
loading...
Comment Link
BTW: IMO choosing *either* the 10 star rating is completely sufficient *or* the thumbs model is completely sufficient (and also *fixing* the rating scheme — even to 5 instead of 10 stars, rather than permitting that to be configured in the back end — personally I would avoid just having pro/con… because that doesn’t leave room for the “don’t know” case of three-state logics). Back when I was programming to be very sparing with memory, I made my own text editors on based on 5 bits (e.g. having a caps shift be one of the 32 cases, etc.
). I imagine it might be possible to merge data into compact data types — e.g. by merging user with vote — so that bits could be combined into bytes (using an entire byte to store just 1 bit is IMO extremely wasteful). Doing such things could indeed drastically reduce the database size, especially if multiplied by hundreds (or thousands, …) of users. The extraction of individual bits (or groups of bits) ought to be simple (especially if it could be done on the local machine).
Well, now you’ve already got my 2 cents 3 times — if I did this a lot more you might have to open a bank account!
loading...
Comment Link
Thanks, I appreciate the input.
loading...
Comment Link
ah, one more time!
— an example:
4 state logic
0: No Vote
1: Thumbs Down
2: Thumbs Up
3: Don’t Know
Hence, such 2-bit pieces could be byte could be packed into a byte 4 times:
A: Self-Standing Evaluation (regardless of context)
B: Evaluation as a reply / comment
C. Evaluation as related to individual blog
D. Evaluation across entire MU / BP community
I think it would also be cool to think about *qualitative* measures — e.g. Person X is “computer-programming expert”, person Y is “medical expert”, Z is “dog expert”, etc. I expect such sophistication is of much more importance / significance than being able to vote at 10 different levels of agreement / disagreement.
Have you ever used http://jyte.com ? If not, take a look at it (it incorporates such ideas) and a similar approach might be very rewarding!
loading...
Comment Link
Hello, and congratz, you did a really good job with this plugin. It is full (a bit too much) and I’m sure the next version is gonna be awesome.
I would to suggest you and idea about caching the data. My website host is really slow. Around 4-8s for pages to be generated (without caches). That’s why I’m using WP Super Cache.
The way you load using Ajax works well but I think you can do more on it. Because stars loaded (If i’m not wrong) are calling a link generated everytime someone is seeing it. I saw you are calling 1 page for all the stars display in a page. This is a good improvement.
My idea is to cache the stars result (I say “stars” because I’m using that feature but the idea is for all the plugin) inside static file. I don’t think this is hard to do. The way I’d do it is using permalink and regenerate the static file everytime someone votes.
One of the main issue is to manage all the stars ratings in 1 link. Because I’m sure it is not a good deal to separate them (even with static files).
What I’m doing now is to use a rewrite rules and to modify the javascript call.
If you think the idea can be good, I’d be happy to talk about it with you.
Alan
loading...