Suppose player's scores determine their rank within a their division within a tournament. The, points are allocated according to their rank. The website hosts seasonal scores and tracks players cumulative points.
Thus, I am seeking a rewards system via php/mysql that would allow players to redeem their points for merchandise.
I have seen "points systems" for user interaction via web sites and only assume a similar system could be set up using player's performance points as described above.
I do not have PHP or DB coding abilities but feel this entirely possible. Has anyone seen a similar scenario as I have described? Just looking for thoughts and comments from those more knowledgeable than I on this subject. Thank you.
I, as well, felt it was possible. I have just have not seen any real world examples with similar circumstances. The "points and rewards" systems observed on the web seem to award points based on user interactions with the site rather than "on field" performance.
Possibly, the better question would be is where does one go to have such a system developed (allowing that I personally do not and will not have these abilities)??
Related
I recently came across this script that extracts friend rank data from the currently logged-in Facebook profile and presents it as a table.
After trying the script personally, I became puzzled as to why certain individuals were consistently ranked higher than others. The rank seems to refresh daily, so I have experimented with various user interaction, and this shifts many entries appropriately; however, the same 'certain individual(s)' would often (with no discernible interaction) arbitrarily move up in rank.
My question is this: is it possible that this rank is being affected by other, external profile's usage data/habits?
In the interests of privacy, it seems very unlikely that anything but personal habits would influence this ranking, but my own and other peoples' usage anecdotes seem to suggest 'arbitrary' movement that would only be explained by external data.
I cannot seem to find a definitive answer to this elsewhere.
Any input would be greatly appreciated.
I have built a recommender systems which has tens of thousands of items and their feature descriptions, but no user profiles as of now. I am looking for pointers to approaches that can help me bootstrap the system, so I can do some evaluation. I would appreciate any pointers to papers/applications that have addressed this problem.
How to deal with the cold-start problem depends a lot on your specific application.
An easy way of dealing with the user cold-start problem is to present the new user with random items, or the most popular items, or hand-selected items, and start learning from them.
Another way is to present users with a questionnaire, and then present items to them according to the results. Or you directly show them items/products and let them rate/select the ones they like.
Also note that in web-based system you usually know some things about your users: Which operating system/browser they use, where they (roughly) come from, which language they speak.
All this information can be used.
Papers:
see the Wikipedia article on the topic
My answer to another question on StackOverflow lists some papers for dealing with new items - most of the methods would also be applicable to new users.
Another approach is to select products/items that will help you most for learning about the user. Just out of my head, you can find them by querying Google Scholar for "recommendation" and the terms "decision trees", "active learning", "user cold-start", and so on.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We are starting to use Kanban and my boss just asked me a question, as one of two people with prior Kanban experience within the group, that I don't really know how to answer.
My previous experience and training with Kanban had developers pulling stories in from the backlog by priority, in our case that was the topmost card. However, my boss would like certain stories to go to the developers that have domain knowledge for particular areas. For example, let's say Joe has the most experience in working with Contracts and a contract story comes onto the board. He would like Joe to be the one to work on that particular story.
This, to me, feels a little "off" and could lead to some developers having significant extra work due to having worked in any given area of functionality. My previous experience with Kanban worked under the assumption that any developer should be able to pick up the next card and figure out what to do and that this practice would eventually eliminate any single functionality area experts and level out developer expertise over time. However, I can also see how using subject matter experts can help move a story through the process faster.
What is the most "Kanban" way of handling priority vs. expertise when it comes to pulling in the next story?
Every system I've ever worked with allows a little bit of developer-level of prioritization. If the next card has the absolute (top-down driven) priority, then you have to pick that card. Mostly, though, I tend to work in places where "these next 6 cards are up, pick the one you like". This gives the developer a little bit of room for type of work he or she prefers. Plus, it gives the developers a greater sense of ownership since they did get to pick (to some extent) the work they were doing.
Regarding your example, it's a little off base. In an ideal world any developer should be able to pick up any card. In reality, this isn't always true. If I give this project to Jim, it might take 2 days. If I give it to not-Jim, it make take all week. This is a sign! What information sharing is missing? How do you get the other developers to understand the Contracts component as well as Jim?
If the priority is a little bit gray, this stuff tends to work itself out. All the other developers know that Jim can handle the Contracts stuff. However, if Jim has no capacity, then someone else must take up the challenge. Kanban is supposed to alert you to blocked stories.
Kanban is great for visualizing work flow, limiting WIP, and exposing bottle necks.
Henrik Kniberg has a great book, 'Lean from the Trenches'. He talks through many techniques he has used in real world examples. He described one approach to having avatars (that represent developers) that can be placed over task to show who is working on what.
One idea for your situation, would be to use this avatar approach to pre-assigning who should work on a task in the buffer leading into development.
If those pre-assigned tasks are not causing bottlenecks and flow is natural, everything is good. If they are causing bottlenecks early in your flow, you have a problem, but now you have an easy way to visualize and see that it is the pre-assigning that is causing your bottle neck!
A Kanban system shall display the real process. If the manager is assigning stories to developer then the system should reflect that. This can be done in several ways, you could have a specific item for developer X or you can write the developers name on the card. Another option is to have one swim-lane for each developer.
However, all of this is probably not good from a "global" perspective. You should share your Kanban data with your boss. What are your lead-times, what is your throughput etc? Then you should invite the boss to the process improvment meeting. How are we going to improve our figures? Hopefully he sees that Joe probably will be a bottleneck if he is assigning tasks directly to him. Teach him Littles Law, teach him about bottlenecks and Lean in general.
Don't forget to make your policies explicit, that is, it should be written on the wall how your prioritzation policy looks like. Good luck!
In google's prediction api page, it says we can use it for recommendation of webpages / products...
Can someone please show me how, for example:
I have 500,000 members purchased history
I have 2,000,000 products in 200 different categories
I have user-X just signup, asked him 15 'like' / 'dislike' product questions (user's taste)
Now, i want to suggest/recommend user-X with a list(e.g. 500) of products which he most likely willing to purchase
Thanks a lot
If you are not specifically tied to Google API fow whatever reason, explore using Mahout. This is a basic use case for the Mahout Recommendation mining.
https://cwiki.apache.org/MAHOUT/itembased-collaborative-filtering.html
The Google Prediction API, as currently implemented, is great for classifying data into a discrete set of categories, however, as noted in the documentation:
Avoid having a high ratio of categories to training data in categorical models.
Try to have at least a few dozen examples for each category, minimum.
For really good predictions, a few hundred examples per category is
recommended.
The Prediction API's classification doesn't work well when the ratio of categories to examples is high and in the example you sketched the relationship is one-to-one because you are trying to find the user whose liked product list is most similar to the user of interest (to find a set of promising products to recommend). In this model, each user is a unique category.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working in a small company and weeks away from deploying a web-app that will be used a lot. Everyone at one location will have to learn to use it, and although I think it's pretty easy and intuitive I may be biased.
I've written a help guide with plenty of screenshots that's available on every page, but I'll still need to train everyone. What's the best way? How do you take a step back and explain code you've been working on for weeks?
First try to avoid the training:
Perform usability testing to ensure your web app is intuitive. Usability testing is a very important aspect of testing and it is often ignored. How you see your system will probably be very different as how a new user sees your system.
Also add contextual help as often as you can. For example when I hover over a tag in stack overflow, I know exactly what clicking it will do, because it tells me.
Also this may seem obvious, but make sure you link to your documentation from the site itself. People may not think of looking in your documentation unless its right in front of their eyes.
About training documentation:
Try to split up your material into how your users would use the system. I personally like the "trails" option that Sun created for their Java tutorials. In this tutorial you can do several things, and you can chose on which trail you'd like to go.
Support random reads in your help documentation. If they have a task to do in your web app, then they should be able to get help on that without reading a bunch of unrelated content.
Make sure your documentation is searchable.
About actual training sessions:
If you are actually performing training sessions, stay away from explaining anything related to your code at all. You don't need to know about the engine to drive a car.
Try to split up your training sessions into very focused aspects of your system. If you only have 1 training session available to you then just do one specialized use case of your system + the overall description of the system. Refer to the different parts of documentation where they can get help.
Letting the community help itself:
No matter how extensive your documentation is, you'll always have cases that you didn't cover. That's why it's a good idea to have a forum available to all users of the system. Allow them to ask each other questions.
You can review this forum and add content to your documentation as needed.
You could also open up a wiki for the documentation itself, but this is probably not desirable if your user base isn't very large.
Few ideas:
Do you have some canned walk-through scenarios? Don't know if it is applicable for your product, but I built a pretty substantial product a couple years ago and developed some training modules that they'd work through - nothing long, maybe 15 minutes tops for each one.
I put together a slide presentation that hit the highlights to talk about what it does. I would spend about 10 minutes going through the app's highlights to familiarize them with it before doing the hands-on stuff.
People don't tend to read stuff, unfortunately. You could put hours and hours into a help document, and still find that folks simply don't read it or skim over it. That can be frustrating. Expect that answers that are in your guide will be the topic of questions your users will have.
Break up any training you do into manageable chunks. I've been to a full-day training exercise before and the trainer broke it into short pieces and made it easy for me to get the training topic in my head. You don't want to data-dump on them because their eyes will gloss over and you'll lose them.
Ultimately, if your app is highly usable, it should be a piece of cake. If it isn't, you'll find out. You might want to have a few folks you know run through your training ahead of time and give you constructive criticism on it. Better to fix it before the big group is trained. You'll be more confident in the product and the training materials (whatever they are) and you'll likely have a better training experience.
If applicable, provide an online help/wiki/faq for them. Sometimes that is helpful.
Best of luck!
You should really have addressed this issue a lot earlier in the development cycle than you are doing.
In my view the ideal scenario for corporate software is one where the users design their own application and write their own documentation and I always try to strive for this. You should have identified key users early on and designed the system with them (I try to get my users to do basic screen designs and menu layouts in Excel or similar - then I implement that as static pages and review before writing a line of significant code, obviously they won't get the design right first time, but it's your job to guide them - and ideally in a way where they think they came up with the correct design decisions, not you :-) ).
These users should then write the user documentation from this design in parallel with you developing the system. I have never seen help documentation delivered by a IT department/software company used significantly in a corporate setting. Instead what happens is the users will create their own folder of notes and work-arounds and refer to this (in fact if you're ever doing system analysis to replace an existing system finding the 'user-bible' for the old system is a key strategy). Getting the users to write their own documentation up-front simply harnesses what will happen anyway - but this is vastly easier if the users feel they have ownership of the system because they designed it themselves in the first place.
Of course this approach needs commitment and time from your users, but generally it's not that hard a sell. It's trite, but working as a facilitator so the users can develop there own system rather than as a third party to give them a system pretty much guarantees user acceptance.
As you are where you are you're too late to implement all of this, but if you can identify a couple of keen, key, users and get time from them to write their own documentation then that would be a good move. If you can't get even that then you need to identify an evangelist who you can train to be the 'departmental' expert and give them 110% of your energy to support them.
The bottom line is that user acceptance is based on perception, and this does not necessarily correlate with how usable an system actually is. You have to focus on the group psychology of this as much as the reality of the system, which tends to be tricky for developers as we're much more factually based than most people.
I'll be looking into something like this too in the next few months.
In your case, hopefully the UI has already undergone user acceptance testing. You say you work in a small company. Is it possible to get the least tech-savvy person there to try it out? In fact, get them to try it out without any guidance from yourself except for questions they ask. Document the questions and make sure your user-guide answers them.
The main thing for me would be logic and consistency. If the app's workflow relates logically to the task it has been designed to accomplish and the UI is consistent you should be OK.
Create a wiki page to describe the use of your system. Giving edit rights to the users of your system lets the users:
update the documentation to correct any errors in the initial release of documentation,
share any tips on usage they may have found.
share unusual uses for the system that you may not have thought of.
request features.
provide any workarounds they've found while waiting for the new functionality to be implemented.
Try a few users first, one or two in a small company. Mostly watch, help as little as possible. This tells you what needs to be fixed, and it creates an experienced user base - so you are not the "training bottleneck" anymore.
Turn core requirements/use cases/storycards into HowTo / walkthroughs for your documentation.
For a public training, prepare a 10..15 minute presentation (just that, not more!) that covers key concepts that the users absolutely must understand, than show your core walkthroughs. Reserve extra time for questions about how to solve various tasks.
Think as a user, not as a techie: - noone cares if it's a SQL database and you spent a lot of time to get the locking mechanisms right. They do care about "does it slow me down" and "does something bad happen when two people do that at the same time". Our job is to make complicated things look easy.
It may help to put the documentation on the intranet in an editable form - page "comments", or wiki maybe. And/or put up a "error wiki" for error messages and blips - where you or your users can quickly add recomendations, workarounds and reasons for anything that does not go as expected.
Rather then train all those people I have chosen a few superusers (at least one person from each department) and trained them to teach the rest of the employees. It is of course vital that those super users are
well respected in their departments
able to teach
like the application
The easy way to ensure that they like the app is to have them to define the way it should work :-). Since they should work with this app each and every day they are the prime stakeholders, no matter what management states