Plugin: SageAlert

[Slugger]

Out of curiosity, what would you plan to do with the notification on the web server?

[razrsharpe]

Originally Posted by Slugger

I'm starting to lean back towards the way it is now except replacing the list boxes with checkboxes. I like the matrix idea, but there's no way to display it in a decent manner. Since the text of each column heading can vary greatly in width, the grid will look horrible. Still haven't made a final decision on this one though.

How about vertical text and limit to X characters with the rest of the characters getting cut off. People should still be able to figure out what notification type it is. The reason i like the matrix idea is it gives an at a glance view of everything without having to open up popup boxes etc.

Alternatively you could also have the events across the top since that is static text and you can control what is displayed/how it looks. then down the left is the different notifications.

And another suggestion:
- Separate sage notification system Errors, Warnings, and Info into three distinct notifications.

Btw, thanks for making the location of the tabs static, much easier navigation now

[darcilicious]

Originally Posted by Slugger

What about the contents of the folder? Based on what Jetty is showing, it would seem the folder is still there, but everything inside of it is being deleted.

C:\Users\USER\AppData\Local\Temp\Jetty_0_0_0_0_8888_SageAlert.war__sagealert__.vqxzmx_5637211617970637763\webapp\sagealert has 19 objects including a gwt folder

C:\Users\USER\AppData\Local\Temp\Jetty_0_0_0_0_8888_SageAlert.war__sagealert__.vqxzmx_5637211617970637763\webapp\WEB-INF has three folders and web.xml

C:\Users\USER\AppData\Local\Temp\Jetty_0_0_0_0_8888_SageAlert.war__sagealert__.vqxzmx_5637211617970637763\webapp\WEB-INF\classes\com\google\code\sagetvaddons\sagealert\client has 72 items

etc.

Plenty of stuff as far as I can tell...

[Slugger]

Originally Posted by darcilicious

C:\Users\USER\AppData\Local\Temp\Jetty_0_0_0_0_8888_SageAlert.war__sagealert__.vqxzmx_5637211617970637763\webapp\sagealert has 19 objects including a gwt folder

C:\Users\USER\AppData\Local\Temp\Jetty_0_0_0_0_8888_SageAlert.war__sagealert__.vqxzmx_5637211617970637763\webapp\WEB-INF has three folders and web.xml

C:\Users\USER\AppData\Local\Temp\Jetty_0_0_0_0_8888_SageAlert.war__sagealert__.vqxzmx_5637211617970637763\webapp\WEB-INF\classes\com\google\code\sagetvaddons\sagealert\client has 72 items

etc.

Plenty of stuff as far as I can tell...

Based on the output you gave before, the SageAlert.html file was deleted from the '.../webapp/' folder. The next time you just end up with the dir listing instead of the UI, go back to the folder and see if everything's still there. Either the contents of the dir is being wiped or Jetty is getting confused. I run on XP so if it is a Vista thing then I have no way of testing it, but as I say, it appears something is wiping the contents of the temp dir - and I can promise you it's not SageAlert. So it's either:

• Something external is wiping your system temp dir
• Jetty + Vista isn't playing nice

If it's the former then adding these lines to the SageAlert.context.xml file might help:

  <Set name="tempDirectory">
    <SystemProperty name="jetty.home" default="."/>/webapps/SageAlert
  </Set>

Add that block right above the last line [</Configure>] in the file. However, doing so will most likely break hot deploy abilities for the app, which means that any future upgrades/downgrades of SageAlert will require a stoppage of SageTV, unzip, then restart SageTV.

[Slugger]

Snapshot 534 now available.

* Add remaining user configurable settings to settings tab (more monitor sleep settings and date/time display settings)

* UI touchups

* Add 'Playing Media' notification type to Growl server

534 is feature complete for v1.0.0. The only issue outstanding is what to do with the alerts tab. A big matrix isn't going to look right/good so I think it's going to be as is except replace the list boxes with a series of checkboxes for each alert type. Those who have been testing, please continue to do so with 534 and report back.

[Slugger]

Originally Posted by razrsharpe

How about vertical text and limit to X characters with the rest of the characters getting cut off. People should still be able to figure out what notification type it is. The reason i like the matrix idea is it gives an at a glance view of everything without having to open up popup boxes etc.

There is no way to make text vertical, I've been investigating ways to do it for the last day or so. The best I could do is create images of vertical text and then use those images for column headings, but that becomes a lot of effort and not the kind of thing that gets me all that excited.

Alternatively you could also have the events across the top since that is static text and you can control what is displayed/how it looks. then down the left is the different notifications.

Shorthand for the event types is just going to confuse people - those who have been using it might survive, but new users need some kind of decent description as to what an event is doing.

Replacing the list boxes with checkboxes still seems like the way to go at this point, but nothing's finalized nor have I ripped out the current GUI widgets yet.

And another suggestion:
- Separate sage notification system Errors, Warnings, and Info into three distinct notifications.

Hmm... yup, I agree.

[Slugger]

Originally Posted by Slugger

Snapshot 534 now available.

<snip>

534 is feature complete for v1.0.0.

Originally Posted by Slugger

Hmm... yup, I agree.

Ok, so 534 isn't feature complete. Keep the ideas coming...

[jsonnabend]

Originally Posted by Slugger

Out of curiosity, what would you plan to do with the notification on the web server?

I look at it as an easy way to interface with external applications. For example, someone asked for a way to run batch apps based on an alert. It's trivially to write a small webserver to receive the post and fire off a batch file.

How much work is involved in coding up a post-to-webserver feature? I imagine it's fairly quick.

- Jeff

[razrsharpe]

Originally Posted by Slugger

There is no way to make text vertical, I've been investigating ways to do it for the last day or so. The best I could do is create images of vertical text and then use those images for column headings, but that becomes a lot of effort and not the kind of thing that gets me all that excited.

bummer that there is no built in way to accomplish vertical text...

Shorthand for the event types is just going to confuse people - those who have been using it might survive, but new users need some kind of decent description as to what an event is doing.

good point... popup help box?

Replacing the list boxes with checkboxes still seems like the way to go at this point, but nothing's finalized nor have I ripped out the current GUI widgets yet.

my suggestion is then to to have the notifications with a expansion box [+] that would expand the checkboxes on the same page (no popup)... similar to windows explorer and folder drill down... like this:

[+]Sage Error Notification

Email 1 []
Email 2 []
twitter []
etc...

[+]Sage Warning Notification

Email 1 []
Email 2 []
twitter []
etc...

[-]Sage Info Notification
[-]New Recording Notification
etc

i know its a crude representation but hopefully you get the idea...also i have no idea how hard that would be to code/implement... Then if someone wanted to see everything at a quick glance you could have a expand all button (and collapse all). it will get to be a pretty long web page potentially but then all the notifications are still on the same page... no popups to deal with.

[darcilicious]

Just a quick follow up -- to be honest, I had problems following your last post so what I did was deleted SageAlert.war from the installation directory, re-unzipped .533 and it's all working fine (as a hot deploy). I think I really only run into problems when updating the software so I'll follow the same procedure on the next update and see how it goes.

As always, thanks so much for your help, this is a great app and I really appreciate your hard and excellent work on it!

[Slugger]

Originally Posted by jsonnabend

I look at it as an easy way to interface with external applications. For example, someone asked for a way to run batch apps based on an alert. It's trivially to write a small webserver to receive the post and fire off a batch file.

How much work is involved in coding up a post-to-webserver feature? I imagine it's fairly quick.

- Jeff

Yes and no. Yes, posting an event to a URL is rather straightforward, nearly zero effort, but the real work comes in defining and documenting the post data. I can post the data to a URL, but unless I thoroughly document how that data is being posted and how to pull it out of the post request, it isn't much use to anybody. I actually like the idea and see great potential in it, but writing a formal spec doc on the data format of the posts is a little bit of a turn off (at least for the immediate future). Remember, I have to keep the scope of these plugins such that I'm able to contain the maintenance of it so as much as I like the idea, it probably goes to the back burner for now. I'm back to work tomorrow so these 2-3 snapshots per day efforts are about to wind down. Won't say no (especially b/c I really do like the idea), but writing a doc defining the process isn't "fun" so it'll end up becoming an issue ticket for action later on (probably after v1.0.0).

[jsonnabend]

Originally Posted by Slugger

Yes and no. Yes, posting an event to a URL is rather straightforward, nearly zero effort, but the real work comes in defining and documenting the post data. I can post the data to a URL, but unless I thoroughly document how that data is being posted and how to pull it out of the post request, it isn't much use to anybody. I actually like the idea and see great potential in it, but writing a formal spec doc on the data format of the posts is a little bit of a turn off (at least for the immediate future). Remember, I have to keep the scope of these plugins such that I'm able to contain the maintenance of it so as much as I like the idea, it probably goes to the back burner for now. I'm back to work tomorrow so these 2-3 snapshots per day efforts are about to wind down. Won't say no (especially b/c I really do like the idea), but writing a doc defining the process isn't "fun" so it'll end up becoming an issue ticket for action later on (probably after v1.0.0).

For the time being, why not post exactly the text you send via email and let the user parse it? No need for anything too fancy.

- Jeff

[GKusnick]

Originally Posted by jsonnabend

For the time being, why not post exactly the text you send via email and let the user parse it?

Because that would lock in that particular textual format, so that even minor cosmetic changes would run the risk of breaking other people's code. In this thread we've already seen a few suggestions for tweaks to the email format. Such tweaks wouldn't be practical if other programs were parsing it.

I think it's better to define a separate HTTP post format and leave the email format for purely human consumption.

[Slugger]

Originally Posted by jsonnabend

For the time being, why not post exactly the text you send via email and let the user parse it? No need for anything too fancy.

- Jeff

Could, but that has no use at all. If you look at the example of wanting to trigger batch files for system messages: If I just post the text of the alert, then you have no way of knowing what type of alert it is (unless I limit a URL to only attach to one event, which isn't how the rest of the app works and really narrows the functionality). In order to be useful, I have to post an encoding of the actual SageEvent object being fired. And then I have to provide instructions on how to decode it into something that would allow a user to determine just what type of event they've just received.

Again, it's almost zero effort to actually do it. The obvious choice is to just encode the SageEvent object to a JSON object and post that. Easy enough, literally 30 minutes of effort. But now I've got to go and write a doc explaining what fields are in this JSON struct and what data each field contains. I know it's probably not much more effort on top of writing the code, but any software developer will tell you that documentation just feels like more effort. Then furthermore, I now have to go write a test servlet or PHP script or CGI program or whatever that actually consumes these alerts so I can test the SageAlert code properly. Again, maybe not much more effort still, but the sum is starting to add up. If you (or someone) knows Java and wants to help then I'll lead the effort in adding it, but if it's going to be a solo effort on my part, then it's probably a post v1.0.0 kind of thing.

[Slugger]

Snapshot 535 available. SVN commit message (changelog) pasted below:

Replace the confusing list boxes with checkboxes; remove the popups for configuring events; add events for each specific type of system message (info, warning, error; also kept the original one that will notify on any system message)

[jsonnabend]

Originally Posted by Slugger

Could, but that has no use at all. If you look at the example of wanting to trigger batch files for system messages: If I just post the text of the alert, then you have no way of knowing what type of alert it is (unless I limit a URL to only attach to one event, which isn't how the rest of the app works and really narrows the functionality). In order to be useful, I have to post an encoding of the actual SageEvent object being fired. And then I have to provide instructions on how to decode it into something that would allow a user to determine just what type of event they've just received.

Again, it's almost zero effort to actually do it. The obvious choice is to just encode the SageEvent object to a JSON object and post that. Easy enough, literally 30 minutes of effort. But now I've got to go and write a doc explaining what fields are in this JSON struct and what data each field contains. I know it's probably not much more effort on top of writing the code, but any software developer will tell you that documentation just feels like more effort. Then furthermore, I now have to go write a test servlet or PHP script or CGI program or whatever that actually consumes these alerts so I can test the SageAlert code properly. Again, maybe not much more effort still, but the sum is starting to add up. If you (or someone) knows Java and wants to help then I'll lead the effort in adding it, but if it's going to be a solo effort on my part, then it's probably a post v1.0.0 kind of thing.

Yeah, I hear ya. In the end, it's pretty low on the list, I would think anyway.

Thanks again for the great work.

- Jeff

[razrsharpe]

snapshot 535 is working great. I really like how you did the layout for the Alerts tab, simple clean and easy to understand and navigate. Also thanks for making the date user configurable looking pretty fantastic...

Thanks

[wayner]

I agree with razrsharpe the new layout is better - still too early to tell if the emails have been killed but I trust that you have done so.

[GKusnick]

Some quick first impressions:

Connecting to the servlet for the first time, the first tab you see is the Alerts tab, which does nothing useful at this stage, since there are no notification servers configured. To set those up, you have to go to the rightmost tabs, which seems unintuitive. Seems like the first thing you ought to see when setting it up for the first time is some sort of wizard screen that walks you through the necessary steps in the right order. At the very least, the Alerts tab should display a helpful message telling you what to do if no notification servers have been configured yet.

When I did go to the Email tab and set up a server and email address, and then clicked back on the Alerts tab, my newly configured server still didn't show up. I had to reload the page to get that to happen. Is there a way that the Save button on the Email tab can force a reload?

I'm confused by the multiple Save/Cancel buttons on the Alerts tab. Does each Save button save only that section? If I change four sections, do I need to click four different Save buttons? Seems like one ought to be sufficient.

Likewise on the Email tab; seems like one Save button should suffice for all settings on that tab.

[Slugger]

Originally Posted by GKusnick

Some quick first impressions:

Connecting to the servlet for the first time, the first tab you see is the Alerts tab, which does nothing useful at this stage, since there are no notification servers configured. To set those up, you have to go to the rightmost tabs, which seems unintuitive. Seems like the first thing you ought to see when setting it up for the first time is some sort of wizard screen that walks you through the necessary steps in the right order. At the very least, the Alerts tab should display a helpful message telling you what to do if no notification servers have been configured yet.

Agreed... a friendly message should appear when there are zero configured notification servers. Admittedly, some kind of wizard setup deal would be nicer, but that won't happen.

When I did go to the Email tab and set up a server and email address, and then clicked back on the Alerts tab, my newly configured server still didn't show up. I had to reload the page to get that to happen. Is there a way that the Save button on the Email tab can force a reload?

Yes, it was working that way; some kind of regression has crept in, probably as a result of my changes on the alerts tab. That will be fixed.

I'm confused by the multiple Save/Cancel buttons on the Alerts tab. Does each Save button save only that section? If I change four sections, do I need to click four different Save buttons? Seems like one ought to be sufficient.

Likewise on the Email tab; seems like one Save button should suffice for all settings on that tab.

Yes, currently you'd have to click the save button for each section to save the changes in that section, but I'm not quite done with the alerts tab yet. What's there is the first attempt of getting rid of the list boxes. I do plan on moving to a single save button for the entire tab.

The email tab, not so much. The smtp settings are hidden away b/c it is a completely different section and once you configure that once you're very unlikely to ever have to touch it again. But if you do, then I want to keep it separate from configuring notification email addresses so it will probably stay as two separate save buttons.

I'm back to work so the snapshot frequency is definitely going to die down, but the issues mentioned here will definitely be addressed in the next one.