What's up

[Jeff Lindsay]

Seriously, tell me what needs to be done to get more help from you guys. We can be so much more than any of the commercial alternatives and yet we have a reputation for not working. I take the blame for that entirely and I'm working on THE solution this weekend. 

But otherwise, what's up? What does Notify.io need? What do you need to help? I've got a vision for this thing that goes well beyond any of the stuff the "other guys" are doing. Should I share that publicly? Do we need a better contributor guide? Do we need features? Better marketing?

Start brainstorming with me...

--
Jeff Lindsay
http://progrium.com

[Abi Raja]

Better homepage/usability so it starts being useful to users immediately. Should be as easy as (1) Download (2) Get notifications from their favorite websites (Twitter, Facebook, etc.).

- Abi

[Jeff Lindsay]

That means we need services to pump notifications into Notify.io -- either we work on that (what you were working on) or we instead focus on ways to make it easier for developers to drop-in notifications to their users that doesn't require them to know about Notify.io. 

Btw, here was the original vision document from July 2009: http://growlfm.pbworks.com/FrontPage.2009-07-18-21-52-50

[Ben Newhouse]

First, the stability is the biggest issue - I've tried to integrate Notify.io a couple times only to be frustrated by the server appearing down.

The current default for notifications in web apps is very clearly e-mail (think Facebook).  Both consumers and developers are used to this.  As it stands, Notify.io is basically pitching to developers that they should quit cold turkey and use growl for communicating with their users.  Along the same thread, setting up a working way to e-mail your users is generally a pain in the ass (especially from EC2) for developers even though it's essentially what is required for every web app.

Basically, what I'm saying is it might be interesting to think about playing up an e-mail output because it plays to a frustration that developers often face and it's what consumers are used to.  It's effectively a trojan horse to build traction after which you append to your notification email - "switch to the real-time future! use growl!" and we start to fulfill the vision that we all have for realtime notifications.  This is a great sell to smaller companies, but not for the larger players (FB et al.)  Although Abi, you talked to the FB guys about notifications at some point/right?

I'm not sure how this plays / would play with the open source service model though - e-mailing can also be a pain to maintain as a service.

[Ben Newhouse]

note that when i say "Notify.io is basically pitching to developers that they should quit cold turkey" I don't mean that anything on Notify.io says "you can't use e-mail", but rather, developers have limited time to implement things and since e-mail isn't played up it seems like a risk to bet that all of your users will use growl when you know everyone will use e-mail, even if it isn't as awesome.

[Jeff Lindsay]

That's a good idea about the email. I've thought about that separately. 

Other thoughts? I'm hoping for more tactical approaches to getting more contributions...

On Fri, Aug 20, 2010 at 4:37 PM, Ben Newhouse <newh...@gmail.com> wrote:

[Ben Newhouse]

oh right, maybe if someone who knows more about app engine could write up a wiki page on how to get the notify.io code running on a personal playground (either on appengine or the development environment you can set up on your laptop) so we can test stuff.  i may have come close to trying to set up my own mirror to debug everything but it wasn't completely clear how to configure all of the various different clients to point to said mirror.

basically a big barrier with notify.io, is that I can clone a git repository, read python, understand stuff, but there's a lot of implicit infrastructure provided by app engine that i'm not familiar with and could only be understood if i spent serious time figuring out how app engine works/how to set up a local dev environment/etc.  i'm sure it's actually really easy, it's just a matter of searching around enough to grasp all of the subtle details that are obvious to anyone who's used app engine a lot.

so in essence what i want to see is - what are the exact steps for me to get a locally running version of notify.io that i can fully test to i can start fixing bugs and adding features?

[Jeff Lindsay]

Ok. That helps. Anything else?

[Hunter Gillane]

Jeff - I'll send you a different email later this weekend but wanted to contribute a bit to this discussion as well. It might be cool to have a public tracker project, I know some open source projects have had success with that. I recall that it came up on the mailing list at one point, but I'm not sure what came of it.

--
Hunter Gillane
President - ACM UCI Chapter
hunter....@gmail.com
(949) 370-3783

[Jeff Lindsay]

Public tracker? Like bug tracking? Or status tracking?

[Hunter Gillane]

Sorry, should have been more specific. What I meant was actually setting up a public project with Pivotal Tracker. You can set a project to be public, and when anyone visits the page there is a big button to join the project.

By having some stories prioritized in the backlog, people might have an easier time knowing what to work on. I realize that this would require a bit of work to keep the backlog up to date, but it might be helpful.

[Jeff Lindsay]

I've had a bad experience using Pivotal (as much as I love it) for open source projects... I did set up a Lighthouse tracker: http://gliderlab.lighthouseapp.com/projects/55825-notifyio

[Mike Wille]

Installing and setting up the client is the single biggest issue for users.  Just about every call I've had is related to getting the client configured via the downloaded text file.  It even trips up power users.

[Roger Clark]

I think what you should do is decide exactly who to target with this
sort of thing... are you trying to get your average user to start
using this and big Web services to publish notifications for a wide
audience, or do you want to stick with the power users who're using
this to send notifications from their IRC clients and custom apps?

The latter is obviously what you are doing now, and while you may not
be succeeding at the job right now, I think it seems to be the right
direction. Turning it into a mainstream service for the everyman seems
like it would involve a complete rethink of how the entire service
works, from registration to downloading your notification app, to
configuration on the Web (the current "sources and outlets" idea is a
little unintuitive even for people who understand what this is
supposed to do), marketing, etc.

If you're targeting the power user, all you really need to do is make
a good product that technically-inclined people can use and enjoy. I
think this is a much easier goal to achieve.

I also think you may be too optimistic in your hopes that coders will
jump in and start developing the service itself with you. Most open
source projects that have multiple, hard-working contributors started
out with a single person driving the product until a point where it
was usable and attractive for people to use, much less work on. When
trying to attract developers, I think you should focus more on getting
people to target Notify.io with their notifications than getting
people to help you with the backend or client software. People want to
work with (or on) things that already exist and have a vision, not
half-baked or hypothetical products -- otherwise, they'd just go off
on their own and implement their own vision.

--
Roger Clark
roger...@gmail.com
www.rogerclark.org
614.859.6502

[Jeff Lindsay]

All good feedback, thanks.

[Jeff Lindsay]

Roger, what's your opinion of what it should look like for regular users?

On Mon, Aug 23, 2010 at 11:08 AM, Roger Clark <roger...@gmail.com> wrote:

[Roger Clark]

Ah -- I was saying that I don't think you should try to target
"regular users" (normal people). I think that's a bit too much.

But if you meant the current kind of user, then I would suggest the
following changes:

- Redesign the website so that downloading something and getting
something running ASAP is the highlight.
- Maybe a simpler, easier explanation on the page instead of a big
weird video (I still haven't bothered to click Play and I've been
using this for like a year)
- Present "sources" and "outlets" to people in a simpler way. It's
obvious that the most important "outlet" to you is the desktop
notifier (Growl). The descriptions and terminology just needs to be a
lot less generic and more geared toward getting the important stuff
set up. And where do you get "sources?" It's really not obvious on the
page how to set stuff up... if you have no "sources" it's obviously
completely useless.
- An actual logo/icon might be nice. The apps could definitely make
use of it when indicating compatibility with your service...

etc.

[Jeff Lindsay]

One thing I've been thinking for a while is going back to marketing it as a platform for developers, so that the end-user experience stays mostly on their site or on a page of Notify.io made for users of that app. It requires certain overall design changes, but it means that a) we focus on marketing to developers, b) developers market to users, c) power users can sort of "upgrade" to the full Notify.io experience and take control of all notifications, etc. 

This strategy requires making certain parts of Notify.io (labels, client experience) regular user friendly, but would, for example, make the marketing on the home page very developer oriented. 

Thoughts?

-jeff