Re: Pop-up message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :-)

> 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.

And that it won't work with all the popup blockers.

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 can drive a sounder in the target browser, but need kicking in the

A sounder?  You mean like make my browser make noise?  ICK!!!

> 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.

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.

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.

> 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.

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)
.
.
.

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.

"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

-- 
Like Music?
http://l-i-e.com/artists.htm

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux