I'm having an issue with my bot changing an unexpected page. For example, I have a sample application where you order a pizza. It goes like this:
"I want to order a pizza."
Pick your toppings
Pick your type of crust
Speak any special requests (light on the cheese, etc.)
I want to make sure that when the user is on a specific page that it won't jump back to a different page. If it asks me what type of crust I want on my pizza, and I say "pepperoni," it should trigger a "no match," but instead it jumps back to #2, assuming that I am picking my toppings. It shouldn't go back; the topping has already been chosen. With Dialogflow ES I could prevent this from happening by marking the intent with a specific context, but I don't know how to prevent that from happening in Dialogflow CX.
How do I keep the bot on the right path without the user being able to jump around the flow by saying something unexpected? Any help is appreciated.
You say that the issue you're describing only happens in the Start page. That happens because the Start page is not a real page at all.
I suggest you take a look at the documentation, specifically to scoping routes and handlers.
If you use the API, the Start page's routes and handlers actually represent the flow's routes and handlers. So if you specify a route (an intent or condition which maps to a transition) in the Start page, that route will be accessible from the whole flow. At any given point inside of a flow, any and all routes available in the Start page are also available (or in scope) in the following pages of the same flow.
To work around the issue I suggest you place a route in the start page which has a custom condition of true (will always occur when you're in the start page) and a transition to a "Start order" page. From this point use the builder as you've already done, build the next pages with the parameters and intents you're using. With this workaround, each page only allows the transitions specified in that specific page and you can restrict the intents available.
Related
I have a shopping cart I want to embed in a widget/iframe on other users sites, I see three ways of doing this each with drawbacks. Here are options from estimated most to least work.
Recreate interactive shopping cart UI in javascript widget then pass values to server script with AJAX, variables are passed to the main site, when user clicks "checkout" the user is then redirected to main shopping cart site with variables populated from what the entered in the widget.
pros: complete experience
cons: most work to complete creating UI and AJAX request.
Somehow detect if user is coming to shopping cart via iframe, if this is the case have alternate code that opens new window when user clicks "checkout" redirecting user to secure page and getting variables from cart via AJAX to populate final checkout.
pros: mid amount of work, must do AJAX request to get variables from shopping cart to populate final checkout
cons: can we easily detect if site is being accessed from a user within an iframe on another site?
complete entire checkout process inside iframe/widget.
pros: least ammount of work, just embed cart in iframe
cons: will not show https in browser user may be reluctant to purchase
What is the best option?
If you could provide a bit more information, maybe I could offer you an even better option. For starters, what have you built this application with (languages/framework)? Also, would you say your application's functionality is similar to Shopify's in that you allow users to host e-commerce sites through your service? If not, tell us a bit more about your application.
Here's a quick response to the options you provided.
option 1: the only real option as I see it. Whether you're embedding the shopping cart in specifically an iframe or rendering it onto the user's page as part of a template, you should be navigating the customer away to your main site to complete the checkout process. Or at least give them a lot of screen real-estate to work with (a sizable modal for example).
option 2: is messy. You can tell if a request is coming from a remote form (like an iframe) by appending url parameters. But taking the approach you're suggesting with this doesn't make too much sense.
option 3: too heavy unless you take a modal-approach like what I mentioned in response to option 1.
That being said, if you are building an application like Shopify, you should be able to build a template for each user's website that has a section dedicated to displaying a shopping cart pertaining to the current customer's session. No iframes or widgets necessary with this approach. But again, it all depends on the use cases of your application.
If your only concern with Option 2 is detecting if your content is being loaded within an iframe, you can do that with JavaScript by using "top.frames.length" or "top === self."
For example, you could show or hide different conditional form content, or a different submit button, using the following:
if (top.frames.length == 0) {
// Show content if not embedded in an iframe.
document.getElementById('embedded-content').style.display = "none";
document.getElementById('unembedded-content').style.display = "block";
}
else {
// Show content if embedded in an iframe.
document.getElementById('embedded-content').style.display = "block";
document.getElementById('unembedded-content').style.display = "none";
}
As you've stated, the first option is the best in terms of user experience and the most likely to achieve the highest possible conversions. How much better the conversion is compared to the next best solution cannot be objectively measured, as it involves recurring customers, your own brand name, the kind of products, etc. Since the conversion rates will directly affect you (and your company), it's wise to make an estimate first to see if your efforts spent will be worth it in the short and long term.
The second option is the sweet middle ground; you still get brand recognition and customers will have some security reassurance (via address bar); (i)frame detection is easily done by a simple JavaScript comparison: top === window. However, you're losing the continuity and hence likely lose some conversion. If this risk is manageable, I'd go for this option in the short term.
Not being able to see the security certificate directly via the green lock makes the third option the least desirable. However, not all is lost; by clever use of imagery you can still gain some trust with your end-user, as outlined in this image, which is part of a great article from Smashing Magazine.
Your decision should be based on:
what can be done in the short term
what should be done in the long term
how important is secure visual cues to my potential customer
time / money spent on either solution versus revenues (break-even analysis)
I'm trying to track how visitors interact with the price calculator that i placed on my website.
I've tried placing events and virtual pageviews in different places and events (onClick, onMouseDown, onMouseOver, in href attribute, onChange in the input tag). No matter what i do - no events or virtual pageviews are tracked, though i can see the __utm.gif requests for everything i want to track in FireBug, but nothing in GA reports.
Here's the calculator i'm tracking (it's in Russian, the event i'm trying to track is the big orange button).
Firstly, I do see a _trackPageview() call passing "/virtual/trees/calculate" on various onmouseover,onchange, and onclicks, and at face value I see no reason you shouldn't be seeing "/virtual/trees/calculate" show up in your pages report, but google officially states that it takes up to 24 hours to see data.
Second, I do not see any event tracking on your page. I do not see any code for it, nor do I see any GA calls showing it from random interactions on your page. If it is there, you will need to give detail about where it is and how it is coded.
Third, do you see the page view for the actual page? Which account/profile are you looking at? Because when I first load the page, I see two separate hits to GA happening, the first to account/profile # "UA-25026876-1" (which is from your on-page code) and the second to account/profile # "UA-20200270-1" (which is happening from a counter.js script include), and the second one is where your virtual page views are going to.
Say I have a site with pages. Pages are ranked based on the number of times they have been viewed. It is good for a page to be highly ranked because it will make it show up higher in my search results. Hence, the author of a page may try to game the system to increase that particular page's views.
So how do you prevent that while still keeping a quasi-accurate count?
I have come up with the following "scheme":
A user can only affect the page view once per session. This is what I would normally expect. If a user returns to the site later and views the page again, it should count as another page view.
The problem is that this makes the page view increment vulnerable to a script that clears its cookies before each request. The easiest solution to this problem would be to save the ip-address and only allow the same ip-address to increment page count once. This however has several major drawbacks; First of all, this would potentially take up a lot of storage, and second of all would prevent users on big LANs from incrementing page count. Lastly, a user cannot revisit a page and increment the page view more than once from the same ip. I can live with that, but would rather live without it.
The best method I can come up with off the top of my head would be to save the last X ip-addresses, and not let anyone from these ip-addresses affect the page view count. This would effectively stop any (simple) script from raising the page view count. Furthermore it would probably be a good idea to add a delay to the display of actual view count (basically keeping two counts and a datetime field for when the "display" count was last updated with the "actual" count, something I believe is done on the SE sites).
This is not a perfect solution, so I would be happy to hear your suggestions and/or comments.
Don't prevent: monitor and handle.
I would use a very different approach. Let the page views stay the same, but have reporting in place to looks for view-gaming. If a page gets gamed, you can find out who is responsible, give them a warning and a page-view penalty. If it continues, ban them.
I think that you should consider the reported characteristics of the browser as well. Browser fingerprinting has been done before and is well publicized. You can then figure out some pretty advanced heuristics on determining whether the same user is trying to game you. But don't publicize that you're using browser fingerprinting of course. Also, it won't stop incognito mode, but I'm just trying to give you one more avenue of thought to follow, in addition to your current IP oriented strategies.
I have a simple form that searches through the 2000+ issues of a 3rd party webcomic. (Easy, it's like xkcd: http://url/number
That form is as easy as possible, is like this:
What number do you want?
User writes a number, clicks ok, and goes on the 3rd party website on a new tab
Then, my form asks a question: "Did you find that issue memorable? Enter the name here, and we will add it to the "best issues" in home page"
When the user will write the name of the issue, it is added to the database (pending moderation by me)
So, I supposed this design is the easiest and convenient that users can find.
Unfortunately, NONE of the users (maybe a 2% behaved correctly) will actually read what I asked. Some of the issues are offline, and gives a 404. On that issues users will write in the textbox a completely wrong title, and correctly capitalized!
It's like if i would name http://xkcd.com/627/ as "The Great Adventures of Jack Smith"
Users are from around all over the country, with different browsers, and have a different cookie.
I cannot believe that my users will not read what I ask, it is a WHITE PAGE with a button that disappears when clicked and a textbox.... easier than that???
Maybe i should put a checkbox with "I acknowledge that this form is for submitting memorable issues, not for fun"? Oh, who will read that?
Or maybe i could enable the textbox only if the user has effectively clicked the link?
Do your users understand your site/service?
I, for one, don't remember (web-)comics by their issue number, but by their content. When asked what xkcd comic number I would like to see, I'd probably input random numbers like 42, 123 or 666 or something.
After you make me guess for a number you ask me if the associated comic is particularly epic, then you ask me to do some data entry for it to put it on some kind of hall of fame. Honestly I do not understand what the logic is behind inserting titles for non existing comics -- are you sure they don't actually land them on the comic page for "The Great Adventures of Jack Smith"? The 2% of your userbase probably noticed the issue in the URL you generated for them, addressed it and typed in the right title. Or, maybe, they are typing the name of the comic they actually wanted to see instead.
There's a simple way to know. Have your mom use it and do not correct her if she makes mistakes. All mistakes she makes are your fault, not hers.
Without having the text of the labels you have put it's harder for us to second guess what's going wrong than it is for you.
Try it!!
You could try parsing the title of the page and obtaining the title yourself
OR you might want to request the username/handle.
Once the user enters the details and clicks SUBMIT, Show a confirmation page ( preview of how the submission will be listed). Make sure to include the username/handle as the person who submitted it (This brings a sense of responsibility to the guy who submits). Remember to keep a back button to allow the user to go back and make the necessary changes ans submit again.
Allow users to create profiles on ur site (they maybe as simple as stackoverflow's profile system. here's mine for example). Unless he is logged-in, submissions posted as anonyomous. Rest same as above.
NOTE: There might be a slim possibility that, U are be being targetted by spam / captcha bots. Hence the random text entries. still. do implement the above. A better UI never hurt anyone. Right??...
I am developing an issue tracking application in Django, mostly for a learning exercise but also for my own projects - and I am looking into using some AJAX for "enhanced" usability. For example, allowing users to "star" particular issues, which would add them to their watch list. This is implemented in a lot of sites, and is often AJAX - as the URL that the user is viewing doesn't need to change when they click the star.
Now, I am wondering what kind of response to return from my star_unstar view - that detects whether the request is being made via AJAX or not.
At present, if the request is an AJAX request, it returns just the section of HTML that is needed for the star, so I can replace the HTML in the star's parent DIV, so as the star appears "on" or "off", depending on the user's action.
However, I would much rather return some kind of JSON object, as it just seems more "proper", I think. The problem with this method is that the javascript would have to modify the star image's src attribute, the href on it, and the link title also, which seems a lot of work for such a simple feature. I am also looking into in-line commenting in the future, but I want to get a feel for how things "should" be done before I start coding lots of JS.
What is the general consensus when implementing features such as this, not just with Django, but all frameworks that operate in a similar way?
When I work with Ajax my main concern is usually to limit the amount of data I have to send. Ajax applications of this type should be very responsive (invisible if possible).
In the case of toggling a star, I would create the actual on/off states as CSS classes, StarOn and StarOff. The client will download both the off and on star when they first visit the page, which is acceptable considering that the star is a small image. When you want to change the star appearance in the future, you'll only be editing CSS, and won't have to touch the javascript at all.
As for the Ajax, I'd send back and forth one thing -- a JSON variable true/false that says whether or not the request was successful. As soon as the user clicks on the star, I'd change it to the StarOn state and send out the request. 99% of the time Ajax will return true and the user will not even realize that there was some sort of delay in the web request. In the rare case where you get a false back, you'll have to revert the star to StarOff and display an error message to the user.
I don't think your question relates particularly to Django or Python, as you point out at the end.
There's a lot of personal preference in whether you return a blob of HTML to write into the DOM or some serialized data as JSON. There are some practical factors you might want to take into account though.
Advantages of HTML:
- Easy and fast to write straight into the page.
Advantages of JSON:
- Not coupled to the front-end of your application. If you need that functionality anywhere else in the application, it is there ready to go.
My call on it. It's only a relatively trivial amount of HTML to update, and I'd probably go for returning JSON in this case and giving myself the extra flexibility that might be useful down the road.