GfW 2.0.9 feature request regarding non-callback clickable URL's

[ToddA]

Hello,

I'm working to integrate GNTP into the open source Network Caller ID (NCID) project (http://ncid.sourceforge.net). A fairly common feature of similar CID applications is the ability to include a URL in the notification to do a reverse phone number lookup on the web. This can be used, for example, to determine if a phone# belongs to a telemarketer.

I already know that by including a line like this in a NOTIFY request:

     Notification-Callback-Target: http://800notes.com/Phone.aspx/1-646-630-0031

the user can click on the notification as it comes in and be taken to the URL. This works, but there are a couple of improvements that I'd like to request:

Request #1) Allow the Notification-Text (and maybe Notification-Title) to have parts of its text underlined. This would provide the user a visual clue that Something Will Happen if they click on the notification. Notice that I said, "click on the notification" (which is the way it works now) and I didn't say, "click on the underlined link." Although it would be nice to be able to have Notification-Text say something like:

     Notification-Text: <a href="http://800notes.com/Phone.aspx/1-646-630-0031">1-646-630-0031</a>

this seems like it might be a hard thing for GfW to do. So my suggestion is a compromise -- still recognize a Notification-Callback-Target as a URL, but then allow something like this:

     Notification-Text: /u1-646-630-0031/u

where "/u" represents a toggle to underline text. I would want the flexibility in not having to underline the entire text, especially if I'm using newlines to force line breaks:

     Notification-Text: /u1-646-630-0031/u\nIncoming Call\n05/05/13 02:57PM

which would appear as:

     1-646-630-0031

     Incoming Call

     05/05/13 02:57PM

Because there's currently no visual clue that a notification is clickable, this should look to the user like something they are already familiar in doing, i.e., they see something underlined and they click on it.

The alternative that I can think of to do in the mean time (other than to be sure to mention the clickability feature in the NCID documentation) is to use up another line of precious screen real estate giving instructions:

     1-646-630-0031

     Incoming Call

     05/05/13 02:57PM

     Click to lookup the number.

I would rather NOT save a line of screen real estate by combining two lines into one long one:

     1-646-630-0031 (Click to lookup the number)

     Incoming Call

     05/05/13 02:57PM

     

because I know not all Displays can handle long text lines. This means keeping each line short.

Request #2) Allow notifications to be clicked when viewing History, too, in both Tile View and Details View.

Thanks for listening!

Todd

[Brian Dunnington]

I will respond to the request for underlining in another post when I have some more time, but request #2 has been brought up several times before. You can search this group for other discussions about it, but the two main reasons that I have hesitated to add the ability to re-trigger the callback when viewing the notifications from History are:

1. Growl supports both socket-based and url-based callbacks. Although a url callback could potentially be re-triggered at a later time, a socket callback can not (since the socket was long ago closed once the initial notification was received and handled). As such, it would appear to the user that some notifications were still clickable from History while others would appear to not be working. It really isnt up to the user to understand which behind-the-scenes mechanism the notification was using for callbacks, so I havent wanted to introduce that confusion.

2. Even if url callbacks were allowed to be re-triggered, the application may not be expecting that the callback could be triggered multiple times. For instance, if you have an incoming phone call and clicking the notification answers the call, what will happen if you click it hours or days later? Or if you have a support ticket notification app that assigns the ticket when a user clicks the notification - will it re-assign it if clicked again? The context is lost when an undetermined amount of time has passed since the notification initially arrived. (It would be fair to say that the sending application should bear the burden of handling multiple callbacks from the same notification and fail gracefully, but since the existing behavior has been and implied rule that callbacks would only be triggered once, it would require all existing applications to re-address the issue).

Those two reasons dont mean I will never add this capability, but give some insight as to why it works the way it does right now.

--
You received this message because you are subscribed to the Google Groups "growl for windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growl-for-wind...@googlegroups.com.
To post to this group, send email to growl-fo...@googlegroups.com.
Visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[ToddA]

Hi Brian,

I can see I was not completely clear and I think I created confusion when I described my attempts to use Notification-Callback-Target. I'm looking for a non-callback URL capability. I do understand the issues you raise with callbacks, but that is not something NCID supports. Of course I have no idea what it would take program-wise so I can only throw out the idea of having GfW just recognize URL's in Notification-Text and Notification-Title, and the absence of Notification-Callback-Target to trigger what I'm asking for. Either that, or maybe have a new NOTIFY header called Notification-Target to distinguish it from the callback one.

[Brian Dunnington]

Making some of the notification text trigger one url while having other parts of the text (or the notification background) trigger another (via the callback url, if provided) seems like it would be confusing. If the user clicks the non-callback underlined url, should the notification still close? And should it also trigger the callback url if specified? Right now the concept is: one notification, one action - that means the user doesnt have to worry about which part of the notification they clicked on. I am always open to hearing new use cases though, so maybe you can explain a bit more how you envision it working.

[ToddA]

Hi Brian,

Thanks for being willing to work with me on this. I would envision the two URL methods to be mutually exclusive.

For the sake of discussion, suppose there really was a new NOTIFY header in GNTP 1.1 called Notification-Target for non-callback URLs. There would need to be a check that there is no Notification-Callback-Target at the same time.

Alternatively, I suppose there could be just Notification-Target and its string argument could determine callback or not. Maybe something like:

     Notification-Target: x-growl-callback://<url>

But replacing Notification-Callback-Target with Notification-Target would break current GNTP 1.0 installations and I was looking for a way to have the least impact in that regard. That's why I thought it might be simpler code-wise to define a new header for GNTP 1.1, with the spec modified to say you can either have Notification-Target or Notification-Callback-Target but not both.

>If the user clicks the non-callback underlined url, should the notification still close?

Yes.

With mutually exclusive URL methods (callback and non-callback), the users could still click on any part of the notification. The use of the underlines would convey visually that Something Will Happen if they click on a URL-enabled notification, vs. no visual indication at all that the capability exists. From the perspective of the History screen, non-callback URL's would still have their underlines to let the user know they can be clicked on longer after the notification was originally received. Notifications with callbacks would