HHC. Brainstorming, part 1

What I’m going to do next is just go through that feature wishlist I came up with 13 years ago, and put in the earlier post, and roughly dissect the items and see if I can’t come up with a practical feature list of some kind.  I’ll extract a running todo list from these little brainstorming sessions and keep them in some kind of special post someplace (I’m sure I can do that here in wordpress somehow.  I’ll figure it out.)

Ordinarily my inclination would be to lay all of these pieces out on 3×5 cards or a huge whiteboard or something, so I could design it from scratch (top up and bottom down, sorta meet in the middle.)  But as an experiment I’m going to just try and get things going as soon as I reasonably can, looking for low cost inter-operable pieces that I don’t have to write myself.  Yeah, maybe I get half way through and realize the approach won’t work.  That’s absolutely fine.

One architectural note that’s going to figure largely in my designs:  I’m not giving up my data.  The master location for all of my data MUST be on the machine at my feet.  Perhaps I’ll publish some data to a web service, but strictly as a client, if at all.

Let’s begin at the beginning then, shall we? I’ll try taking two at a time.

  1. A real-time ticker application that will be updated using RSS. (Not the current “refresh to update” silliness in aggregators of today) Publishable schedule items (to the rest of the world or a specific subset at my option)

What does that mean?  It’s really a few different pieces of functionality.

  • “real-time ticker”  That’s a marquis or on-screen display system for events.  So, if I’m going to go with a monolithic application, a single scrolling window.  BUT let’s keep things separate and use a desktop push alert system. THAT means something like Growl or Snarl that will capture updates (whatever they are, we don’t really know yet) that will be published at will.  Since Growl seems to have the larger market presence, I’m going to start with that.  It pops up windows with notifications published from “someplace.”  I assume I’ll be able to digest RSS somehow and feed it to Growl periodically.
  • “Publishable schedule items” To be frank I have NO idea what I meant by this.  Publish to who?  I already have my schedule.  For now I’ll translate this to: “Pick a calendar application such as google calendar, a desktop PIM application, Mozilla Thunderbird’s ‘Lightning’ extension or similar that will allow me to sync items between devices, making it available to other HHC components.”  Fortunately I already use Thunderbird for email (it’s really useful for managing more than one email account, much less the dozen plus I’m juggling) and, while I find the Lightning extension a bit cumbersome, it might be a good candidate

2. To subscribe to lists of events that are occurring around my area geographically, and virtually and have those events appear in a calendaring application. To use a blog or blog-like publishing environment (I’m thinking Zope with  CMF) for a personal desktop heads-up-display console from which I work at all times.

  • Ah, the heads-up-display item.  I really wanted to have an application with a gui component that would live on the right side of my screen containing a little calendar and some other stuff (which we’ll get to later), such that if I maximized other application windows, it would still be, not “always on top” but would shrink the client window so that it was always there (but not obscuring anything.)  In older versions of Windows, you could create an application that would do that.  I’m not at all sure if you can in Windows 10 or not. This needs research.
  • Subscribing to local event lists is easy.  I just have to find and select some.  Things like meetup, etc.  There are a few sites, local subreddits, yadda yadda.


  1. Install Growl and publish a test event or two.
  2. Create test case for publishing an RSS feed of some kind to Growl.  (I may have to digest a feed and publish some other kind of event.  I’ve no idea.  Needs proof of concept work.)
  3. Put calendar items in Lightning (already installed) and see if it’s open enough that I can get to them.  Start looking for alternative if that’s not the case.
  4. Find out if I can create a client-diminishing sidebar application window that will stay up at all times.
  5. Dig up a half dozen feeds or subscription services (even if I have to screen scrape some html) with local events (specifically local to me.  Make it work first. Make it generic later.  Premature optimization is the root of all evil.)

There. So I have five discrete todo items to take care of.  Frankly this all shouldn’t take more than a few hours of poking around and testing stuff out in one coding platform or another.

And we’re off.