I have some sort of a heatmap and I can see how my users are using my website. Now I know where they are clicking, how much time it costs to complete a set of instructions, how much do they navigate between pages, etc.
So given that I have information with of this kind:
12/12/2014 12:45:00 - User pressed button 1 on page 1
12/12/2014 12:45:15 - User pressed button 2 on page 1
12/12/2014 13:00:00 (15 minutes delay) - User pressed button 3 on page 1
Now comes the hard part - how do I process this kind of information? For example how do I know that the user is lost on my website (if there is 15 minutes delay - does this means that his phone rang or my UI is bad?). And also - how can I find some patterns in large amount of data - say every third user spends 15 minutes after the second click to find what he has to click next.
What is the correct approach here? Thanks.
In order to derive useful information from raw data you need some context. You need to be clear about what expected user behaviour is and, where appropriate, what you are aiming for the user to do (eg. buy a product, register, make a comment etc.).
For example, if you have an event splash page with a big button to book a place, and you find that a lot of people click on that button very soon after they arrive, that's probably a good thing. If you have a page full of important information that you want people to read, and they click away just as quickly - that's really not a good thing.
It sounds obvious but so many people fall in to the trap of trying to evaluate user behaviour without being clear about the context - and without acknowledging that the very same number can mean very different things depending on that context.
Evaluate each page of major section of your site and outline what is there, and how you'd expect users to interact with it. How long would you expect a user to spend on that page? Where would be the logical place to go next? Is this a logical place to leave the site (I booked, I'm done), or is a user leaving the site here a failure? And so on. Then compare these expectations to the reality you see from your heat map.
Don't get too hung up on individual cases - if one person took 15 minutes on a page that should take 30 seconds, that was probably the phone ringing. If 90% of visitors take 15 minutes, then your page needs re-evaluating.
Lastly, pay as much attention to what people don't do as what they do. Everyone's eye is drawn to the bright spots on a heat map or the rows at the top of a chart with big numbers. With analytics, a lot of the most useful information is what you expected to see people doing, but they aren't. Again, to realise this information you need to have defined that expected behaviour.
Related
I have seen some references to the Auto-learn function of Watson Dialog but I can't find coverage in any of the documentation. Can you point me to a source of information on how best to use Auto-Learn?
Thank you for your feedback, we are always working to improve our documentation.
For your immediate benefit, auto-learn is a bit of a misleading name for a feature t, but the name has stuck.
Autolearn has become the "did you mean..." with four bullet points that shows when a user sends an input that has no direct matches.
A little history...at one time, we thought that if a user typed something, saw the did you mean... and clicked a link, their intial input must have meant the same thing as the one they clicked, the system should automatically remember that.
Imagine this:
"What are your credit card fees?"
Did you mean... 1. apply for a credit card 2. cancel a credit card 3. pay your bill
click apply for a credit card
The user was simply interested in that, but obviously the two DO NOT have the same meaning. So we realized thats a bad idea, the system will learn incorrectly. However, we still call it auto learn.
It seems that sometimes timeline items (just text) arrive instantly and other times they take forever... Is there a way to send one at precisely the right time?
You can send the notification at a precise time.
timelineItem.getNotification()
.setDeliveryTime(new DateTime(oneMinuteInFuture.getTime()));
That's a java example, where oneMinuteInFuture is a Calendar object set to one minute after now.
What happens when you do this is the card is inserted in the timeline immediately, but the notification is delayed until the specified time. So the card goes in right away and one minute later I get a chime.
There is an unaccepted issue related to this at the issue tracker you might want to star and follow, it appears that this functionality might change in the future.
Our Utilty has one single table, and it has 10 million to 50 million rows, There may be a case we need to show 50 million rows in a single page html client page, To show the rows in browser we use jQuery in UI.
To retrieve rows we use Hibernate and use Spring for MVC. I am looking for best practice in retrieving the rows and showing in UI. Should I retrieve a bulk of thousands rows or two thousand rows in Hibernate and buffer to Web Client or a best practice is there ?
The best practice is not to do this. It will explode the browser memory and rendering engine, and will take too much time to load.
Add a search form to your webapp, make the end user search for what he's interested about, and only display the N first search results, just like Google does.
Nobody is able to do anything meaningful with 50 million rows without searching anyway.
i think you should use scroll pagination (when user reaches to almost bottom of page makes ajax call and load data).
Just for example quick google example & demo
and if your data is tabular then you can use jQGrid
Handling a larger quantity of data in an application must be done via virtualization. While it's true that the user will be overwhelmed by millions of records, it's not exactly true that they can't do stuff with it, nor that such quantities of data are unfathomable.
In practice and depending on what you're doing you'll note that this limit crops up on you with just thousands of records. Which frankly is very little data. Data centric apps just need a different approach, altogether, if they are going to work in a browser and perform well.
The way we do this is quite simple but not all that straightforward.
It helps to decide on a fixed height, because you will need to know the max height of a scrollable container. You then render into this container the subset of records that can be visible at any given moment and position them accordingly (based on scroll events). There are more or less efficient ways of doing this.
The end goal remains the same. You basically need to cull everything which isn't directly visible on screen in such a way that the browser isn't paying the cost of memory and layout logic for the app to be responsive. This is common practice in game development, only the world that is visible right now on screen is ever present at any given moment. So that's what you need to do to get large quantities of stuff to behave well.
In the context of a browser, anything which attributes to memory use and layout/render cost needs to go away if it's isn't absolutely vital.
You can also stagger and smear recalculations so that you don't incur the cost of whatever is causing the app to degrade on every small update. The user can afford to wait 1 second, if the apps remains responsive.
I recently wrote a program to display data on a set of LCD TV's. The data is for the most part static with the exception of refreshing from the database every 60 seconds. I know screen burn isn't as big an issue with LCD's as Plasma TV's, however, I would like to try and minimize the risk. These screens will be running for 8 hours a day.
I programmed a small square that bounces around the screens on top of all the data. The square constantly changes colors as it goes. I did test that it hits every pixel on the screen. It completes a "cycle" every couple of minutes.
Is that sufficient to mitigate the risk of burn in? Or do I need to make something more complicated?
Discard all the effort altogether, LCDs do not sufer from that problem at all.
And that square is probalby annoying, and even if it were to do any good, it would have to stay on the screen for longer period of time.
And - I wouldn't worry, 8 hours per day is normal. If you are paranod, you can move the window / re-place the text every so.
That is not true exactly. While LCD don't suffer from what burn in actually is. They do have a similar problem, especially when used as a computer screen, or left on a tv guide. An image will stick if left on the screen long enough, usually goes away but it can be permanent.
The program you are describing sounds like it would work just fine.
I've got a WinForms client-server app that displays various offers in a list. Every user (client) has a "rating". An offer consists of various data including a minimum and maximum rating. If a user's rating does not fall in that interval, he should not be able to take the offer.
Of course I could just perform some server filtering and send a list of offers prefiltered for each user to the client application. But that would surely, and rightfully, lead to confused requests "Why isn't this offer showing up? I know it exists, it shows up on [other user]'s screen."
How should I handle this? My favorite solution so far is to grey out the offer and add a tooltip "You can't take this offer because your rating is too high/low" while displaying greyed-out offers at the bottom of the list to leave the actually valid offers easily visible on top of the list.
A disabled option tells the user:
The action is possible.
Just not right now.
But the user can make it possible.
Unless there is some simple action the user can do to change his or her rating (e.g., by selecting some other controls in the same window), do not use disabling and do not show the offers. Disabling may confuse some users who will then hunt around the window for something to do to enable those offers. It’s a great idea to use a tooltip to explain disabled objects, but that’s not a standard and not all users will think to hover the mouse over a disabled option (Why should they? It’s disabled).
Including offers users can’t have, even when disabled, clutters your display, forces more scrolling, and distracts the users from the offers you actually want them to consider. Furthermore, showing unavailable offers can come across as taunting (“ha, ha, your rating isn’t high enough”) and may diminished the perceived value of the available offers by comparison, resulting in lower user satisfaction.
It seems unlikely to me that users are going to go around comparing the offers on their windows, but maybe you have user research saying they do. In any case, you should label the list of offers to make the criteria clear (e.g., “Offers available at your rating” may be sufficient).
If you want to encourage users to increase their ratings, then maybe include something advertising the benefits of an improved rating. For example you could have a link "-Improve your rating- by four points and get -five additional offers-." The first -link- tells users how to improve their rating, while the second lists the offers as a motivator. The latter link should only be there if the offers will still be available if the user actually succeeds in getting four more points.
That sounds like a good way to do it.
As a slight improvement, if it makes sense for your application, you might consider including the actual numbers in the tooltip, e.g.:
This offer requires a rating between 5 and 8. Your rating is 4.