Paywall policy for non game page tabs - tabs

I spent a while looking through Facebook's polices but couldn't find anything mentioning this so hopefully someone here may know.
I want to create a page tab and put a lot of the content behind a paywall, do I need to accept Facebook Credits in addition to the other payment options?
If send the user away from Facebook to signup do I still need to accept Credits?
This is not a Game so the game specific policies don't apply
I am sorry if this is the wrong place to ask a question such as this.
Thanks

If your application is not a game, then the credits migration requirement does not apply to your app whether it's an app in a tab or on canvas (ie apps.facebook.com/YOUR_APP). Only game developers who are accepting payments on their canvas app(s) are required to use Facebook Credits as their sole payment system. There is also an FAQ on Facebook's help center which explains this.

Related

Link Types for Plugins

I'm new to Banno so I apologize if this is common knowledge but I couldn't find anything in the Banno knowledge base. I've looked at link types (https://knowledge.banno.com/apps/partnerintegrations/linktypes) that you over for plugins but couldn't find the one I was looking for. There are blue links above the Banno cards in the dashboard and I'm wondering if I have access to these links. I would like to create a link there for my application. Below is a screenshot of the links I'm talking about.
From what I understand, I have the ability to add my link there but only in the account details page. I would like to add my link to the dashboard page above the section containing the Banno Plugin Cards. Is this possible?
Not 100% certain about that specific location (on the Dashboard above the area where cards, both built-in and plugins, reside). Will check with Product & Engineering teams for clarity. Thank you very much for linking our doc...that helps narrow things down for us!

Tweet the score of HTML5 game without possible tampered values

I'm developing a game in HTML5 (WIP) and came with this hard situation... the game is very simple, you play, you lose or win, and you have a score. Then, the game has the option to share your score, but... how to avoid tampered values?
All I've got so far is a share button of Twitter in my game, when you click it, appears a modal window of Twitter saying: "I've scored X points in this game!" but that text is editable, that means... everyone can change the points and write some tampered values.
Is there a way to Tweet this status without being able to cheat the game score? Maybe there's a way to directly tweet the score disabling the modal window of Twitter that allows to edit the text.
Any solution to this? if not, what piece of advice can you give me to post unaltered scores on social media? (preferably Twitter)
Your help is really appreciated!
In short, no.
You could prevent the modal from allowing the user to enter data, which would stop most manipulation. However, there is no way to prevent users from tampering with their scores in order to falsify them, even after the score is submitted.
Tools such as the Tamper Data addon for Firefox allow people to 'freeze' score submission, and manipulate values as they're being POSTed to the server. Unfortunately, you cannot prevent users from falsifying their scores in this way.
The best you can do is obfuscate your scoring system, making it difficult for people to understand how it works. That won't necessarily prevent them from manipulating their scores, but it would make it more difficult to do so.
Hope this helps! :)
Once suggestions is, you can put post scores as an image which can be base-64 data. Here's the Twitter API for uploading base-64 media data,
https://dev.twitter.com/rest/reference/post/media/upload
You can generate score images using HTML5 Canvas and convert it into base-64 image data using canvas.toDataURL() and pass it to twitter API
Maybe there's a way to directly tweet the score disabling the modal window of Twitter that allows to edit the text.
Yes, you will need to have the player sign in to your app using Twitter. Once done, your app can Tweet on the player's behalf using the API.

How to interface Paypal with Flash for games

I have looked for something like this on Google and on this very site, but only found answers detailing procedures for sites. How is it possible to make so financial transactions can be carried over inside the game using Paypal, or maybe a different site? Is there any API/Library? If possible provide a solution in AS3...
Yes there is a PayPal API for this you would need to look through paypal documents to know to get further information, Apart from implementing this, a while back i had some scripts that would make a basic ECART for PayPal in actionScript, I would i have to check up my back up files to see if i still have them, i had found them through google..
Paypal has a couple short examples of integrating their new Digital Goods payment method into Flash, but it either involves embedding javascript in the html surrounding your swf and talking to it using ExternalInterface, or opening another page in a popup.
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_IntegratingDigitalGoodsInFlash

How can I convince a client that audio on a website is a bad idea? [closed]

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 7 years ago.
Improve this question
I have a client that wants audio to play while the user is browsing the website. Besides the fact that audio is annoying when it starts automatically and plays when you are browsing, I thought of the following technical struggles.
Having to use frames to allow audio to play uninterrupted.
SEO issues with using frames
Having to use ajax to allow audio to play uninterrupted.
SEO issues with all ajax site
Pop-up to allow audio to play in another window
JS pop-up blockers won't allow this
Does anyone else have other technical hurdles that I can use in my defense?
Music on your website is a terrible idea
All who are against music vote for this answer
All who are for music vote for the other answer
It doesn't matter what you or s/he thinks. All that matters is how the customer reacts.
Easy way: see if they'll agree to asking 10 random strangers (who are representative of the visitors you get) and playing music in the background (you can just mock this up) and abiding by their opinion.
Hard way:
If the client won't agree to #1, try the one below (and once they realize #1 costs $30 and #2 costs $300 to do they'll then opt for #1)
How about some objective metrics with an A/B split test: Randomly assign half the visitors to hear music, the other half not to. Then compare conversion rates (or abandonment rates).
Losing customers in the effort to prove a point isn't going to win any brownie points with the client, so I would avoid putting music on without the ability to turn it off. Furthermore, you risk frustrating your user base by defaulting the music to on/loud.
However, in this scenario, you will probably find that most people never turn on the music because they don't realise it's there.
You could ask your users what they prefer the first time they load the page up:
Do you mind if we play music during
your visit to our site?
Sure, go ahead, I love music
Actually, I'd rather you didn't
[X]Never ask me this again
You'll likely find that most of the users say no, and they'll appreciate you not harassing them on every visit to your site. Likewise, those that want to listen to the music can appreciate it without your whole user base being irritated by it.
If the client is unwilling to see how bad of an idea that playing music can be, try to meet in the middle. Maybe add a music player options so users can choose to toggle between on or off. That's the best attempt and what my strategy would be.
Hmm, this is a tough issue because there really is no clear, definitive answer. I like to look at issues like this:
Technical:
If a client wants a feature (in this case sound) perform the due diligence to research if browsers can support that feature, and which ones will not. Come up with numbers to show the client. X feature is only supported in X browser and most people use "this" browser so I would / wouldn't use this feature.
Psychological:
Specifically for sound, study the psychological effects, usability of this feature as it concerns the end user. I will immediacy leave a website if a video or sound starts playing without my permission. I expect a choice, and when that choice is taken away I leave. And at the point where I leave, I'm mad, I hate any user experience where I am left out.
Client is not always right:
So most of us have heard that the client is ALWAYS right. Well to be quite honest, no no they are not ALWAYS right. It does not matter whether your selling websites, or magazines, or working on cars, you have to be there for your client. Obviously if you do good work people will refer you. However sometimes you have to stand your ground with a client. My suggestion is to make sure you do that at the beggining of a project, rather than later. I've turned down projects, or agreed to handle only certain aspects of a site design because I wouldn't be associated with certain features. For example I don't do Flash sites. Not that flash is bad I just don't do it. I give those projects to friends. And they return the favor. If you tell a client upfront that you won't / can't deliver that's a good thing. Don't say yes and then come up with an excusse later in the project, that's where the client will become frustrated with you, and if they complain they are right to do so, and you will loose business.
At the end of the day communication, deciding upfront what you will and will not do will save your lots of headaches.
And as for sound, it has it's time and place. Bands, Flashsites especially those highend national ad campaings for cell phones, or movies can get away with sound. The best option at the beginning of a project is to tell (don't ask) the client that they can have sound, and if it does auto play you will set he volume to low, and have a visable player that the user can control, meaning they can TURN IT OFF, OR LOWER THE VOLUME, these features are not negotiable. If they have a hard time with that, then walk away from the project because they will have a hard time with anything. And don't be afraid to turn down work. For every 3 sites I work on I turn down one.
I recently took on a project that requires sound. I'm kinda in a pickle with my client (he's not mad) but he told me he wanted sound and I offered to use a player, and give control to the end user. He was ok with that. Recently, after checking out the sound player feature he says "No, I wanted a sound to play when you rollover the navigation. The pickle is that he never said that, and I've stood my ground with him about adding that feature. So he's a little upset with me, but we are working it out. He's mostly upset that I want to charge for the extra feature, and I'm not budging. It will all work it. Just an example.
Sorry for the long reply, Good luck!
If someone is viewing your client's web site at work, the music could cause them to click away immediately. That's what happens when audio starts playing on a site I'm browsing at work.
I had this issue with a client. I solved it by doing an Ajax site, but in order to workaround SEO downfalls of Ajax, all the navigation links literally linked to another page. Search engines saw a completely normal site, where navigation links were normal and only the content paragraphs for that one page were loaded in the HTML.
The JavaScript then progressively enhances the page by overriding the link behavior to load the content for the new page. So users with JavaScript got a great Ajax experience, with audio, and only the content div loaded new content.
You can even get around back/forward button issues by marking #pagename in the URL for each page. Upon page load you should check to see if a #pagename is there, and then load the content for that page.
Hope that's clear enough - let me know if you need more details.
See if you can figure out why, from your client's perspective, they want this feature. See if they can give you good reasons. Then you can begin seeing how to meet their goals without necessarily using their methods.
That might help with convincing them, as opposed to resorting to technical concerns. Going technical makes it sound like you don't want to do your job. That's not the case at all -- I'm sure you want their site to be awesome and you will do what it takes to make that happen. It's just that "what it takes" may not be exactly what the client asked for the first time.
There is nothing like a practical demonstration. Find a suitably annoying midi file and loop it endlessly. If the client can stay in the same room for 30 minutes without their head exploding then they have won the right to put music on the site.
Obligatory XKCD.
Myspace
The business stakeholders do not care about your technical worries. So I advice you not to waste time telling them or seek more input.
The business stakeholders do care about money- and that is the major reason why you were hired and a "currency" you can use to "talk" to them. Explain to them things like:
How adding audio can reduce an ability for customers to stumble upon their site via a Google or bing search (SEO)
How audio can be disruptive and make them more likely to go to the competition (which is only a click or two away) (this is your pop-up issues)
The current state of technology and users' expectation will not make this site pretty and give a poor return of investments (Ajax problem you mentioned)
Notice each of these focus on the button-line (profit-$$$) and does not bore the business stakeholders with technical details which is not their problem (but yours.) Speak to them in their language, be frank and realistic and these guys can be wonderful. A demo of an extremely bad site can help if you feel that it helps your cause (but be careful because this can also hurt you.)
Nothing you've listed is a reason to avoid playing audio on their website.
To you and I (and many others I suppose), auto audio is really annoying.
My suggestion is that you explain your feeling to your client.
If your client still insists on having audio, then do what they want. The client is your customer, and the customer is always right.
As an aside, many photographers I know have audio, and while many poo-poo this, they all swear that their clients love it. So I guess to each their own.
Put it on the website and wait for complaints to come in.
Store designs, notes, and specs for client's approval on your own web site. Add music to these pages. Make sure it's music he doesn't like.
This comes down to one of the primary rules of usability: do what the user expects.
The only way I'd consider putting auto-playing music on a website is if it's for a band website with an integrated Flash music player. The reason is simply that the user will expect it. Any other time it's just annoying.
Another point - many users open many tabs/windows at once, so if music starts playing, you don't actually know which site is doing it, which is intensely annoying!
I might cite a precedent to make my case. Identify their space or niche on the internet. Look at other site owners who are very successful in the customer's space. Do they play music? Is it working for them?
Suggest against it, because most internet users actively dislike it. Make a comparison to the blink tags of ten years ago, which also made sites seem less professional to the larger audience.
And if they still want it, do it, because it'll make them happy, and happy customers with terrible work beats unhappy customers with the Best Site Ever. Just leave the site out of any portfolio of your work you put together.
Or, as the genius above already added, add a toggle for music on/off.
Every time you call the client, blare music in the background and say you just opened some website that started playing it automatically.

What should a main page of a web application be? [closed]

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 4 years ago.
Improve this question
Designing a web application, how do you design the main page? By this I mean the page that is displayed to a user after entering the base url, like http://www.foo.com.
It would probably depend on a website, but...
stackoverflow welcomes us with list of questions, no silly what is stackoverflow landing page,
last.fm prestens a kind of dashboard, being very popular lately, kind of personalized landing page for registered users
google welcomes us with a search box, but iGoogle i completly diffrent story - looks diffrent for everyone (well, and that's the point actually).
The other thing is, if the user is logged in (provided the website supports logging in), should we present him a diffrent content there then some new, random incomer? And I don't mean some personalized content, but something completly diffrent, like his user profile instead of main page?
From one perspective it could be good - registered users usually know our site, and get a kind of special greeting as soon as they come back. On the other hand, this could cause problems - when I show a website to a friend, then he goes there from his computer and sees something totally diffrent.
And other thing is, when I show a http://www.foo.com to a friend, and it takes me directly to my user profile / dashboard - this isn't sometimes what I'd like to show everyone, as this might show some of my personal data, etc.
What do you do when you design your web applications? What's, in your opinion, best from user's point of view, do my concerns about the website looking diffrent for registered and unregistered users do or don't make any sense? (Again, I don't mean small diffrences, like hiding huge register now link - but showing completly diffrent view then).
It really depends on the focus of your application, but if you were to generalise I would say determine the one or two most critical paths in your application and focus on those.
Registration is probably what you
want to drive more than anything
else, so make it clear how users can
sign up and get involved.
Make it is easy for existing users to sign in.
Consider the amount of text you have
on your front page and reduce and
pair it down as much as possible. Keep the messages and information you
convey here as succinct as possible.
Provide some content immediately
showing what your application or site
provides. Don't make users follow a
link to access the core functionality
of your site immediately e.g. if
you're building an auction site,
ensure there are listings on the
front page.
Consider your audience. If your site is non-technical, the fewer UI elements you present the better. Portal like sites, with lots of compartmentalised functionality and information can be confusing and overwhelming for many non-technical users.
Make it clear how users can get Help if they require it
Without knowing the business area of your site then it's going to be tricky to answer this, but...
You should get the user into the main flow of your website as soon as possible, and the home page is the best place to do this.
If you're an online store, start showing your products.
If you're a search engine, give the user the ability to search.
If you're a blog/news site, show the user the latest news.
Yes - make the experience for a logged on/registered user better (show them THEIR news, show them their recommended products etc), but the purpose of your site should be obvious and accessible from that home page. Get your existing users into their flow as soon as possible, and attact new users in to your site by showing them the meat of your site.
There are plenty of places out there that discuss good web design, making your site "sticky" etc. Check out SmashingMagazine.com (it's one such site) but there are plenty of others.
Oh, and remember that there's one very important user of your home page that you need to accomodate - search engines. Make their life easy, make the content discoverable and indexable, and drive people to your site via Search.
What I've found works best for me is to "role-play" the end-user's experience.
When they initially hit your site, what do they most want to see, or in other words, what are they most likely to be looking for and wanting to do?
I work on many intranet websites for a very large company, and what I've learned is that a home page that has detailed information of the site and what it does is useless and, consequently, my end-users just skip over it in order to get to the pages that they really need. So, my strategy usually consists in a home page that allows them to get straight down to business and whatever they're there to do.
BUT, that's just for the sites that I create. I think it totally depends on your target market and what they're wanting to do.
For the most part, a visitor landing on your page will already know the gist of what your application is about, so there shouldn't be a need to explain in detail what is is you do. Instead, show them that you have the information they are looking for. Screenshots and screencasts are becoming popular these days as a means of getting this across to the short-attention-spanned user.
For registered users, I'd recommend taking them directly to the primary application page instead of the homepage (unless the homepage is the primary application page). For many apps this is a Dashboard (Flickr, Basecamp, Campaign Monitor). If your app's main focus is the homepage, you may want to show them a personalized version of that page (think Google vs. iGoogle).
With all this said, it really does depend on what you are building. Every application is different and there's no right way to do it - only conventions that work for most.
I would start by looking at the type of tasks that can be performed inside your web app, what's important? what's important when they are a new user? what's important when they are a repeat user? what's important when they haven't even registered yet.
Although all of these things happen on the the same page, it's likely that you'll need to define different states. e.g. If a user is on the homepage and not logged in, should we prompt them to login and register.
Perhaps also look at Personas so you can figure out exactly who will be using the app and what is relevant to them.
It should be whatever makes sense for the application, and this should be verified by testing the application with a group of expected users.
The main page should provide a first-time user with enough visual and/or written information to understand what the application is about. They should have some idea as to what actions they can take to interact with the app and what the outcomes of these actions could be.
I know people hate this answer on stackoverflow but there's only one way to find out what the most appropriate thing for your users is - you need to brainstorm ideas with potential users or at the very least you ask them.
I'm not suggesting that you do a focus group, or put a flawed poll up (neither of those things work). Rather, I'm suggesting that you go out and talk to people who will potentially be in your target users and do planning games with them (like card sorting) or go out and do some user testing with paper prototyping.
Anything else is guessing.