I have a site which authenticates a user for a given time period and on any subsequent page request that time interval is extended. I am wondering how to notify users their time is about to expire without using a js.alert() but also remain accessible.
I have seen some sites where content will slide in from the top and not intrude the user but still be noticeable. The problem I see with this is that it may not update the screen reader's buffer and the users with accessibility needs will not become aware of this.
Suggestions?
The correct method of alerting a user accessibly should be to conform to the WAI-ARIA (Accessible Rich Internet Application) Specifications. Now the documents are only the technical part of your implementation - as with all Internet technology its implementation among screen readers and other accessibility tools varies widely and is difficult to ascertain without extensive testing, but it is certainly the best we've got to work with as of now.
The specifications calls for this type of messages to be marked with the role='alert', and their dialog boxes with the role='alertdialog' attribute. It states that alerts are
A message with important, and usually
time-sensitive, information.
which would certainly fit the bill. Now I'm not sure about your concern about the screen reader buffer problem, but as far as my reading on this subject goes the screen readers that adopt the WAI-ARIA specifications will need to be constantly scanning the page for new attributes and elements, as tutorials like this show, it is even possible to add the alert attribute to elements already present on the page, thus I do not believe that your concern should present a problem to modern screen readers.
You can use some nice JS/jquery countdown and show it to user somewhere on page. Eventually display well looking dialog with alert that session is going to expire, or silently refresh session with AJAX as long as page is opened.
I saw a timer counting down from 10 minutes in the bank account page. It's quite simple, and gives me good information about how much time i have to fill a form before my session will be closed.
Related
At the moment, I'm working on a website that could use some extra user usability, so I want to launch a couple of modal windows to aid users on their first time visiting of a couple pages.
I want to check if it is a users time time viewing a specific page. I've read about how you can run into problems when using cookies to do this. They can be deleted, the user can use a different PC or device, etc.
Also, I want to check for multiple pages if it's their first time viewing, not only directly after login.
I'm guessing a good idea for this would be to make a separate table with the pages in it that I need and setting a boolean for it if it is viewed or not.
Would this be the best way going about doing this?
There isn't a highly reliable way of doing that:
You can use cookies, but as you said, they are not reliable, a user can change PC, delete cookies, change browser, etc.
You can try using an IP address, but that's also not reliable. If a user switches address (which can today happen as you walk down the street with your mobile phone) he'll see the page over and over again. Moreover, if some other user happens to stumble upon the IP address the first user used, he won't see your tour/tutorial.
What I can suggest you is that you use cookies to detect if the user is new, but don't automatically throw the help modules on him, but prompt him using an non-obstructive toolbar at the top or bottom (never a popup window or lightbox).
That way, you get most of the users (because many people use the same browser and computer and rarely delete all their cookies), and even if a user has deleted his cookies/he still won't be disturbed that much.
There is no reliable approach if user is not registered and logged in with her/his username & password.
As mentioned before, there is no reliable way of detecting users ( and detecting if the user visits the site the first time), I also recomend Madara Uchiha's aproach, also you colud use html5 local storage in addition to cookies, both are not 100% reliable
u can however try user recognition without relying on cookies or html5 storage, but this is extremly complicated, u dont want to do this.
Just to satisfy your curiosity about how to do this, check this epic answer on a related question:
User recognition without cookies or local storage
I think, as I believe, there is no way with no solution. I think, a possible way consists of some parameters which first to be said and and finally by considering those, we can be able to talk about possibilities and impossibilities.
My parameters are in the below;
talk about features of a webpage as "User Detection" and detail them
think about reactions (I mean being fast to click on any elements of a page or not) on a webpage
inspect elements
URL injection
other reactions like click on some parts as spots placed on the page
stay on that page up to a time defined for being and checking authorizing
and so some solutions like the ones above.
We have a jquery/php/mysql system that allows a user to log in and review videos built by a system for online viewing. When a user begins reviewing a video, the video is marked as such. But now we've cornered ourselves into the classic browser-based application problem of the user navigating away or closing the browser without completing review. That video would then enter a state of limbo of constantly being reviewed, but never completed, and never re-entering the queue.
Options we have are:
Build a service (which we already have others) to find review sessions that are outside a duration boundary and reset them back into the queue.
Reset review sessions outside a duration boundary when that user logs in. Essentially, if a user locks out a video for review, it'll be unlocked the next time they log in.
A suggestion made to me was to use the php/apache session length and on expiration, reset any pending review jobs. I don't even know where to look to implement this as this is one project on a shared server, so it shouldn't be an apache config, but the reset mechanism would need to know the database credentials to be able to reset it...
The worst solution everyone hates is preventing the user from navigating away with javascript, asking "Are you sure?!"
This system is used by a few hired reviewers, so I'm not exactly dealing with the public here, but I can't prevent users from sharing logins for speedier review, which would knock out the 2nd option above because it would unlock a video being reviewed by someone else using the same login.
There are two good options that won't tax your server. Either:
Run a cron-job every hour looking for review sessions that are outside of the duration boundary. This has the advantage of being transparent to the end user. But it's possible to kill an active session if you're not careful (Suppose the user is operating in multiple tabs).
Prevent users from navigating away with JS. Honestly, this is what I would do since the user is reviewing the video (if they were just viewing it, that would be bad, but since they know they are supposed to be acting, it's ok). Just say If you leave now, the review will be canceled, are you sure?.
Honestly, I'd do option #2. SO uses it, and it works well here. It wouldn't be for every page, just those where there's an active review going on...
When a single video is reviewed on a single page by one person. You can capture the JavaScript unload event which will be fired when the page unloads and the client is leaving the page. Than you can change the state of that video or even show a dialog and let the user decide.
Maybe a ping-pong system may help. In the back you make AJAX calls binded to a video by an ident. When that activity stops, the users stopped. A background process can look for latest ping and when that is, for instance, a hour ago, change it's state.
Your first option is your best bet. You can have a javascript timer on the page updating the lastestActivity record for the video while the browser window is open So you won't get into the corner of a review that takes too long and the unlocker releases the lock prematurely.
Option 2 is problematic for several reasons, some have already been mentioned but taking into account that a reviewer might not log in for a few days (vacation?) will unlock a video for too long unnecessarily.
Option 4 (Javascript onBeforeUnload) Won't cover you in the common cases of a browser crash, OS crash or a power failure. but it is something you can implement in addition.
I want to trace each user time spent in my Facebook application.
I really don't have any idea how to code this, help me out. If someone has any ideas or hints, that will be enough.
I am using Graph API.
Either: Google Analytics
The easiest solution of course is using Google Analytics - FBML (Facebook Markup Language)
has a tag specifically for that: http://developers.facebook.com/docs/reference/fbml/google-analytics
That of course doesn't give you data on what a specific user did, but it is pretty good at telling you the time spent on various pages in your Facebook app. And morally its much nicer not to store what a specific user did exactly on your site.
Or: Self-coded solution
If you do want to track everything specifically, you'll first need to store when a page was accessed using PHP when loading the site and then storing in 10-seconds-intervals (or so) that the user is still present, using an AJAX call. To do that, I'd give the page view an ID and send a request to a page like this *i_am_still_here.php?p={page_view_id}* which takes the current timestamp and updates a database entry for that page view.
This solution has one problem: When a user opens a tab in the background and doesn't look at it for 30 minutes, you don't really want to store that 30 minutes as "the user being on the site".
Also, make sure that with whatever self-coded solution you choose, you have to take into consideration that people might have your Facebook app opened in more than one tab.
Your problem is not Facebook related per se. There are many ways you could implement this, it also depends on your particular application.
You could track every click a user makes (timestamp of the click) and then calculate the time spent from that (last click in session - first click in session). This approach is not very accurate off course since you don't know how many time a user was still using your application after the last click.
One other solution that comes to mind right now, would be to fire a XHR (AJAX) request every X seconds that would also log the timestamp in some storage (db, redis, memcache, ...) and you could then do the same calculation from that. It would be more accurate (depending on your interval X).
You can easily calculate the time spent on Facebook by downloading a software called TimRabbit which is a desktop application and starts automatically calculates your time spent on facebook. It only calculates your live time spent and ignores when you are acting as a idle user.
For details visit: http://etechdiary.com/calculate-time-spent-on-facebook/
We got pitched this idea yesterday. A user visits our site and are marked. Then when they visit other sites like CNN they are targeted with adds for our site. So once they are exposed to us, they start to see us everywhere, creating the illusion we are bigger than we are.
The person pitching it said it was done by cookies. I was very skeptical since I don't believe there to be anyway to see what cookies a different domain has set. So I wanted to try an figure out how it was accomplished. The salesman called this technology pixel tracking.
I have never heard of pixel tracking but from my research I have found that it is placing a 1 pixel image that references a script on another domain with parameters to be executed. My first thought was, OK maybe its possible this way.. But I still don't know how?
Can anyone explain how they are able to mark you as visited our site, and then see this mark on another site? Is it from your IP?
Included at the bottom of the (CNN) website in this case is an img tag like:
<img src="http://www.webmarketingCompany.com/pixel.php?ID=623489593479">
When a user visits the (CNN) website, and the browser renders the page, it sends http requests for all the images as well, including a request to http://www.webmarketingCompany.com for the image pixel.php which includes the ID as a get parameter. pixel.php not only returns an image, typically a 1x1 transparent gif (so it isn't visible in the rendered page), but can do a whole host of additional processing using the ID value; and it also has access to any webmarketingCompany.com cookies, which are also sent with the http request.
Of course, CNN have to agree to include the img tag in their html. Typically it's used as a tracker by third party marketing companies working on behalf of CNN to identify who is visiting their site, what pages they're viewing, etc.
But because it's a PHP script, it can do a whole host of extras, such as setting further cookies. If webmarketingCompany.com also handle ad-serving on behalf of CNN, they can do some creative selection of the ads that they choose to serve.
Such cross-client "pollination" is frowned upon, certainly here in the UK.
What you are describing is pretty standard for all advertisement networks. The only difference here is that they will place that cookie on your site as well.
As long as the browser has "accept third party cookies" set to true, this will work as the salesman said. Most browsers has the setting set to true by default, the only exception I can think of is Safari.
Ok, firstly this is not about forms this is about consistent layout as a user explores a site.
let me explain:
If we imagine a (non-ajax) digital camera online store, say someone was on the DSLR section and specified to view the cameras in Gallery mode and order by price. They then click onto the Compact camera's page. It would be in the users interests if the 'views' they selected we're carried over to this new page.
Now, i'd say use a session - am i wrong?
are there performance issues i should be aware of for a few small session vars ( ie view=1 , orderby=price) ?
Speaking of performances, there should not be much problems with either solutions.
Some things that have to be considered are :
With GET, if an URL gets copy-pasted (in a email or MSN), the other who will receive the URL will have the same GET parameters
is that a good thing, or not ?
On the other hand, session will not be shared, if an URL is copy-pasted
which means the first guy will say to the other "key, look at this", and the second guy will not see the same page ;; same thing with bookmarking, should I add.
GET is specific to each URL
While SESSION is shared accross all tabs of the user
Which means browsing with several tabs at the same time can cause troubles, when using Session, if you don't take care of that
I'd say use both. Store it in the session, but also put it in the get parameters for the page.
Why? This way the user is able to carry his options from page to page, but they are also in the URL so if he sends search results to his friend, his friend sees them the exact same way he did.
No, the session's performance will not degrade by putting those small variables in there. Unless you're storing monolithic arrays in your session, the vast majority of the time loading a session will be reading it from its storage medium (file, database, memcache, etc).
You should use GET in your case.
There is one simple rule in the web development: each page with different content must have it's own address. So, customer can save any page into favorites, send it to a frend. It's pain in the bottom then someone sends you a link to a particular page saying "Look!" but site uses frames and you land at the front page and dunno where to look.
You can save user's preferences into his profile/cookie (not session), but it should be reflected in the address bar as well.
Sessions being used for completely different purpose, shopping cart is an example.
It's a subjective question, it would work either way.
Personally I would go with sessions as it doesn't interfere with the URL so people can bookmark the url if they wanted.
However the argument for that would be if they bookmarked it they might see different things if it was done using $_SESSION.