I notice that you keep naming things soapi. Are you worried that people will think your stuff will only work with Stack Overflow? Why don't you go with something more generic? (just a thought)
–
jjnguyJun 21 '10 at 13:27

@jjn - ahh.. hmm... i guess i am not really worried about that. i generally make it clear what the scope of my code is. in any case, soapi has a nice ring to it. thanks for the heads up though. and i have a handy place to host all things soapisoapi.info ;-)
–
Sky SandersJun 21 '10 at 14:11

i would like to see this beauty on Osx :)
–
systempuntooutJun 23 '10 at 20:40

@system - my abilities on OSX are limited to some shell scripting and mono, so if you want to see it, you have to write it. ;-)
–
Sky SandersJun 23 '10 at 21:37

4 Answers
4

Design Conversation:

in reverse chronological order.

part the Third: in which code poet waxes v1.

After the unexpected divine intervention of Brian, the developer of Growl for Windows, I was able to refactor the evolving custom pin-able update-able displays into much slimmer and much less complex code. The updates are now batched by the server, soapi-notify, and pushed to the notifications that are still registered for updates.

Thanks Brian.

For those that are not quite satisfied with the default displays provided with soapi-notify, the source for the default display is a great place to start writing your own. Be sure to share it here.

There are a few more things that I would like to incorporate into V1 before calling it soup.

the ability to monitor existing questions. keep an eye on questions as they evolve.

extended filtering support. either/or tags using the api methods is a bit limiting. I will use client side filtering to provide a more compelling filter experience.

proxy support - need to set up a proxy to test this.

These will be incorporated gradually over the next month or so. I need to finish some other projects and get a job. Anyone who wants to help out may submit patches and perhaps be added to the team.

Let me know what you think

part the Second: in which code poet introduces vNext.

So, after considering radius' comments I realize that the omission of the vote/answer/view metric was a bad idea, so I redesigned the new notification and console output.

With new custom display:

With plain growl display:

Regarding the other half of the dialog in which the possibility of updating notifications has been realized in the self-updating notifications.

If a notification times out and closes it self, there is no update.

If the notification is 'sticky', either by configuration via Growl or from 'pinning' by clicking the grey lock icon, the notification refreshes itself at as yet to be determined refresh rate.

Compare the 'How to validate HTML Matches W3C standards' question in the screen shot: The console output shows the state of the question when it was pulled and the notification has tracked, in real-time, the votes, views and answers over the last 4 minutes.

This build is in the source repository right now. If you are familiar or would like to make yourself familiar with the process of manually adding a growl notification type, knock yourself out.

A binary release including self-installation of the display will be released tonight.

Coming Up:

By popular demand: A GUI.

The GUI will provide extended functionality:

more control over and more convenient specification of which tags to include/exclude/pin

select and copy your 'ignored tags' from the site and paste them into a text box to omit questions containing those posts from being notified.

select and copy your 'interesting tags' from the site and paste them into a text box to make questions containing those tags 'sticky' by default along with the appropriate background color visual cue.

Let me know what you think.

part The First: in which code poet mixes good idea with short sightedness

I whipped up soapi-notify in a few hours. It actually took more time to publish and document than it did to write.

After using it for a day I am convinced that the idea is much more than a novelty.

I am polling at the recommended 60 second intervals and, funnily enough, I never see a question that is more than a minute old. imagine that. And it brings the point home when I see a stack of questions that are less than 10 seconds old.

So, I am convinced that this is a viable app. With that in mind, lets discuss some design issues.

Vote, Answer and View counts:

It is quite obvious that my soon to be previous screenshots include these metrics in the results and they seemed relevant in that there was non-null data. But this was due to a bug in the time-zone conversion.

In reality - as explained previously, the questions that are being reported are seconds old. There are no votes and there are no answers. So I have removed those data points, which makes the output much cleaner.

Date Output

For the console output, which is persistent and linear, I am including a short time string.
e.g. 12:02:20 PM

For transient notification such as Growl, I am verbalizing the time difference much in the same way you see on the sites.
e.g. 19s ago

Our very own Growl Display

So, not content with the default behaviour of any of the displays (growl notification boxes) that are available in that I would like to let them fade out as normal but i would also like the ability to 'pin' or make 'sticky' a notification. Kinda like a sticky note.

So I created a custom display just for us. Here is the design at full resolution.

I am building it so that all notifications are static height, unlike standard Growl displays, to present a more consistent display. They are just a little wider than most displays I have seen, around 400 pixels. If this turns out to be an issue with screen real estate we can revisit this and re-institute a more narrow dynamic height notification.

I don't fully agree with you on "Vote, Answer count". It's useless if refresh rate is high, with a refresh rate of 5 minutes like the default in senotify value can be interesting. May be the display can be an option.
–
radiusJun 22 '10 at 10:16

In my case, I configure growl to keep notification sticky when idle. In this case it would be great to be able to refresh notification data (vote/answer count) (growl for mac can't do that, I don't know for windows). I think I will work to a better console output in senotify, to be able to always diplay : Question get by last refresh + N older question with still no answer
–
radiusJun 22 '10 at 10:22

@radius - i see your point r.e. metrics. i think it would be unnecessary complexity to optionalize it. I am just going to put them back in. thanks for the perspective.
–
Sky SandersJun 22 '10 at 11:20

@radius - r.e. updates on notifications: there is no mechanism in place for that sort of bi-directional communication. the feedback loop is pretty simple, as it should be. Refresh would have to be built into the display. Hey, i know someone who is building a custom display, maybe he can create them to update themselves? let me ask.... self, could you add update ability to the stack exchange display? sure, self, I could do that. Hey, he says he can do it. but not for mac. they are fairly simple to build, perhaps once i get mine built as an example we can recruit someone to write one for mac
–
Sky SandersJun 22 '10 at 11:22

2

i am the developer of Growl for Windows so i thought i would chime in. you actually can update an existing on-screen display with new data if you want. (few of the built-in or additional displays use this feature though so it is poorly documented). the trick is to set the CoalescingID property on the Notification object you send to GfW. in your custom display, you can use that value to associate existing notifications with the new one and update appropriate. see the 'Meter' display for an example (code.google.com/p/growl-for-windows/source/browse#svn/trunk/… Extras/MeterDisplay)
–
AnonymousJun 22 '10 at 20:45

@brian - hey. good work on growl. I see the meter source but no example of using it. I can understand how pushing data to an existing notification using a key would work and this would be the best strategy in that I could batch the update requests to the API instead of the current implementation that involves each instance of the display polling for itself. My question is how to track which notifications are still open. I assume that I would simply maintain a local registry of notifications as I open them and then respond to a callback in order to remove them from the update list.
–
Sky SandersJun 23 '10 at 1:14

exactly - see this file, line 65 or so: code.google.com/p/growl-for-windows/source/browse/trunk/… the ActiveWindows property will contain a list of open notifications that you can use (as long as you opened them using the Display class' Show() method). then it is just a matter of checking the CoalescingGroup (which also takes into account the sending application do you dont accidently update another app's notifications if your CoalescingIDs collide).
–
AnonymousJun 23 '10 at 1:37

@brian Ahh - i see. I had it backerds. Growl does not handle coalesce, the display does. that makes more sense from every angle. for some reason, i assumed that if i sent the connector a cid that it would find and update the appropriate box. silly me. thanks for the hint. that will allow me to remove a lot of bits from the display and make more efficient calls to the api. I will try to chronicle my foray into building a display in a blog post or two and let you know.
–
Sky SandersJun 23 '10 at 2:04

@brian- thanks for your help. It makes perfect sense and I have a more economical update pattern in place and a much slimmer display deployement. In a case such as this where the display is specifically tooled for my app, does it make sense to simply embed the display assemblies and deploy/update from the app itself?
–
Sky SandersJun 23 '10 at 10:42

1

if your app is going to have an installer anyway and the display is tailored specifically for use with your app, then including the display in the app's installer definitely makes the most sense. alternatively, you can set up the display to use the one-click web install (similar to other displays on the GfW website) so that end users can just click a link and the display will be installed in the right place automatically. if you want more info on that route, post in the GfW discussion groups and i can provide more detailed instructions: groups.google.com/group/growl-for-windows?hl=en
–
AnonymousJun 23 '10 at 16:12

@brian - thanks for that. I don't see a need for an installer, really. It is a console app. What I intend to do is embed the display binaries in the executable and when it is run with -g, simply use Detector to probe for the existence of the proper versions of the display and then, if necessary, stream them out to the proper location. This will allow me to ensure that the displays are synced with the exe. This is pretty important, especially in alpha/beta as I move relatively fast and need to maintain the user experience with the least possible amount of pain.
–
Sky SandersJun 23 '10 at 18:39

@code poet - the display installation solution doesn't seem to be quite right yet, the app crashed with an exception Cannot install or update displays while growl is running. The workaround of installing the display first is obvious and did work out fine, but this user experience flaw will likely hinder mass adoption of this otherwise already pretty slick and useful proof of concept ;)
–
Steffen OpelJun 30 '10 at 10:05

I tried it out on Windows 7 running the latest version of Growl for Windows, and I had no problems:

My only request - please make a GUI!

GUI Mockup

Rather than trying to describe what I would want in a GUI, I'll show you:

The main settings page - you could also add options like "Start soapi with Windows", etc. Ideally, soapi would start minimized as an icon in the system tray. You can also specify the refresh time, force a check, and add/remove sites to check.

Site-specific page - you can add tags on the left to only have soapi retrieve/display questions with those tags, and on the right, you can add tags to be ignored, even if they occur with a favorited tag on the left.

What functionality and features would you like to see in a GUI as opposed to the console? Users will drive the design of this app so don't be shy.
–
Sky SandersJun 22 '10 at 3:57

@code - If you would like, I would be willing to grab your source and make my mockup actually functional
–
Jared HarleyJun 22 '10 at 23:25

if you want to skin s-notify, knock yourself out, no need to ask. My initial forays involved a GUI and I intend to provide one tonight. Something to consider: 'Show Only' and 'Ignore' do the same thing, using different information and must be mutually exclusive. One would either use one textbox and a checkbox or use a radio button group to indicate the tag mode and disable/enable the appropriate box. In the source you will notice that I have already pre-wired for the 'exclude' flag to apply to the tag list I just have not gotten around to implementing it.
–
Sky SandersJun 23 '10 at 0:58

see updated design answer for info on where I am going with this tonight.
–
Sky SandersJun 23 '10 at 0:59

i have been, on-and-off, been working on v2 but work has been getting in the way. i feel bad because I have previously promised a new version but just have not been able to give it the time required. This code could be modified to recognize more sites fairly simply, but the UI would be more work, thus the rewrite in progress. I will be sure to update this post with any progress.
–
Sky SandersOct 28 '10 at 14:36

@SkySanders It would really be nice if soapi-notify was able to query the list of Stack Exchange sites from the API (this api call : api.stackexchange.com/docs/sites). (but it's just a user advice)
–
RiduidelMay 28 '13 at 7:02