|
|
Posted by hitek on 03/01/05 19:09
Is there some reason you can't simply use a javascript alert on the page refresh?
if(isset($queue)){
echo "
<script type=\"text/javascript\">
<!--
alert(\"$queue\");
-->
</script>";
}
>
> From: Lester Caine <lester@lsces.co.uk>
> Date: 2005/03/01 Tue AM 03:18:58 EST
> To: php-general@lists.php.net
> Subject: Re: [PHP] Pop-up message
>
> Richard Lynch wrote:
>
> > Lester Caine wrote:
> >
> >>At the risk of being shouted at because *I* know it's not a PHP problem!
> > Actually, it's a client problem :-)
> Yep - but with so many different ways of doing it, which client method
> would be best ;)
>
> >>I have a page that is being refreshed every 30 seconds or so, and
> >>displays a list of 'tickets' waiting to be dealt with on a list from a
> >>database query. No problems there, but a couple of sites now want me to
> >>add a pop-up warning when a ticket is added that has a staff ID matching
> >>the logged in user.
> >
> > Your first task is to convince the client what an incredibly stupid idea
> > this is.
> Actually it's not - which is part of the problem - these are all private
> networks and this is to replace 'reception' trying to phone the member
> of staff - who may already be on the phone - to tell them an appointment
> has arrived. So I just ant to 'queue' something on the their machine.
>
> > And that it won't work with all the popup blockers.
> Have a handle on that, and the customer knows the problem, they are even
> willing to consider a switch to Firefox if that will help. Tabbed
> browsing with queue's on different tabs makes a lot of sense :)
>
> > And if it did work, it would just annoy the [bleep] out of their users.
> >
> > I know I'm preaching to the choir, here, but I have to go on record with
> > this statement.
> I know all the arguments, but hopefully you can see the problem - how do
> we tell the 'target' that there is someone waiting - and the clock is
> running on performance figures :(
>
> >>I can drive a sounder in the target browser, but need kicking in the
> >
> > A sounder? You mean like make my browser make noise? ICK!!!
> Yep - and if they are on the phone they may not here it either.
>
> >>right direction for a method of adding a pop-up window. Ideally it needs
> >>to be browser agnostic, which is where the problem comes given the
> >>pop-up blockers and other 'toys' that are being added to the browser end
> >>of things.
> >
> > You're not going to defeat the popup blockers in the long run.
> As I said - we have control over machine configurations - to a certain
> extent, and if a user decides they want to be clever it's their
> performance figures that will be affected ;)
>
> > You are better off using clean simple code in an onLoad in your body tag
> > to open the new window. Something like:
> > <body onLoad="window.open(URL);">
> > where the URL loads in that user's recently added items.
> >
> > Either the users will accept the popup and whitelist it in their popup
> > blocker, or they won't.
> That is probably where I am at, but I was looking to see if anybody had
> any other ideas for passing messages. Probably should have explained
> better what I was trying to do, but I often see 'Did you try so and so'
> which provides another avenue to look at.
>
> > And if a lot of them don't accept it, as they shouldn't, that tells you
> > right there what a dumb idea this was. :-)
> >
> > But running around to find code to "defeat" the popup blockers will be a
> > total waste of time -- and you'll end up with something so hacked and so
> > un-maintainable that you'll have to fix it every six months, even if the
> > popup blockers don't find workarounds to block your workarounds that popup
> > the windows that they don't want popped up.
> Already covered that, but there *IS* a need for a controlled way of
> passing messages from the server to the client ...
>
> >>So can anybody point me in the right direction for a CURRENT method of
> >>achieving this, many of the bits I've found so far are somewhat
> >>antiquated, and fail in one way or another :(
> >
> > Perhaps it would be better to segregate the tickets into those associated
> > with the User logged in, and those that are not.
> >
> > Or to at least sort them that way, regardless of their other sorting options.
> >
> > For that matter, don't even *BOTHER* to show me items that aren't mine,
> > unless I specifically ask for them.
> Other people in a department need to be able to see who is waiting on a
> queue, only some callers are appointments, so a browser is left logged
> in with that queue selected so people can monitor things. As soon as an
> appointment is logged, the page changes to a staff ID specific page, and
> as long as it is visible in the background, it can be seen, but 'other
> systems' insist on being displayed full screen, which is what is being
> the pain. If (actually probably WHEN) we can get the applications that
> don't want to share to play nicely ...
>
> > Build a system that detects tickets that sit un-assigned for too long, and
> > randomly assigns them, or, better yet, assigns them based on factors such
> > as:
> > Ticket features (IE, interface tickets to interface team members)
> > Productivity (IE, don't assign as many tickets to your slow team members
> > as your fast ones)
> > User Status (IE, if I'm on vacation, don't assign me anything)
> Already covered - we know the person is in the office - and that they
> are waiting for a caller - They COULD be advised by a telephone call
> (and in some offices I can actually dial the number via PHP), and in
> some offices the telephone system has a voice mail, but the 30-60
> seconds to navigate that when you have 5 - 10:30 appointments all
> arriving at once is what we are trying to bypass. The receptionist has
> the details on their screen, and should just be able to say - take a
> seat and Mr X will see you shortly - and go on to the next caller.
> >
> > That way, no tickets is left sitting there "too long" but nobody has to
> > deal with tickets that aren't assigned to them.
> >
> > Just an idea.
> >
> > In general, though, I only mean:
> >
> > Come back at the client with more than just "That's a dumb idea" (which it
> > is)
> >
> > Come back with a "Here's a MUCH better way to do this" proposal.
> Have you got one :(
> The problem is how to provide an indication they they need to check the
> queue page - what ever is on it !
>
> > "That's a dumb idea" just gets you more headaches.
> > A solution for a better solution makes you look real smart. :-)
> > Yes, this may turn out to be a waste of your time, because the client is
> > REALLY dead set on these popups, and you'll end up being miserable about
> > them not taking your proposal as well... Time to start looking for a new
> > client. :-v
> Not necessarily pop-up, but something to flag the need to do something
> as soon as practical. Pop-up is not right, but can at least be
> controlled in the environment I am working in (government/LA private
> networks). I am looking for some pointers to the 'smart' idea though :)
>
> --
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[Back to original message]
|