Live data from Hacker News

The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

nickoneill.com

31–40 of 48 posts

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#31
post #26

Love the concept, but I found Pipes got very complex to do anything I wanted - a common problem with visual tools. Zapier solves this by pre-configuring tasks that most people want. Also better times for it, with so many web-apps and web APIs around now.

Agreed. Pipes is cool, but as a developer, YQL is so much more intuitive. When I think of accessing data, I think of SQL & REST APIs, not diagrams. But, Pipes is good for non-developers who don't know SQL.

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#32
I remember looking at Yahoo Pipes back in 2007, but perhaps the timing was not right for it back then. Now as the Web is getting more and more ubiquitous and the need for services to talk to each other grows, an approach like this could very well take off.

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#34

The Pipes/IFTTT concept screams for a more open solution, it's too important to be proprietary. I'm always frustrated when I want to use IFTTT but they don't support the services I need. A simple protocol based on HTTP, JSON, and WebHooks could be pretty slick.

I've actually been working on exactly this (but considerably more powerful and in-depth than Pipes/IFTTT) for quite some time now (almost 2 years, on and off). It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned).

Before I link to it, I'd like to apologize for overly generic descriptions currently on the site. I whipped together the entire site in a few days not knowing the exact direction I wanted to take the software, so I left everything pretty vague; I really just wanted some content that at least somewhat described my ideas. I'll put the link at the bottom of this comment so you read all this first.

From a technical standpoint, this is currently where I'm at with it:

- Users create a myriad of widgets that can "interact" with each other; the fullscreen version of Loggur consists of "layouts" of widgets, while the mobile version of Loggur lets you access widgets individually in typical mobile app fashion

- Databases are incredibly easy to create; just add fields to a widget and specify their relationships to one another

- All kinds of special extensions included by default, like automatic importing of various data sources, scraping of websites, cron jobs, PDF report generation, emails, sms notifications, triggers, and graphing

- Everything is taggable for reuse, from the apps themselves to widgets to components to elements to lists and to the data associated with all of the above; you can either "mirror" or "clone" any one of these parts in another app/widget/component by doing a quick search for tags (or if you know the exact path to the part, just enter that); so for example, if you really liked what someone else has made and wanted to reuse parts of it in your own app, you'd do a quick search for it, clone it, and modify it to suit your needs, saving a lot of time

- Data associated with apps can be any combination of public/private, singular (your individual profile), and/or group-specific; you can quickly/immediately switch between views of each

- Permissions on everything; specify who can view and/or edit apps, widgets, components, elements, lists, and/or data

- Appearances are somewhat customizeable and will become much more so at some point; customization currently consists of the basics like colors, backgrounds, and sizes; apps are designed to be scalable to any screen resolution (think large dashboards ;)

- Each one of the pieces outlined above (widgets, components, etc.) can be embedded on your own site(s) through small snippets of code

- Data associated with apps is easily accessible, currently only available in JSON but if for some reason other formats are requested in high numbers, I might do that

- Users can toggle the ability to view app/data updates as they happen in realtime; they can also invite each other (or a Loggur dev if they need help) to take turns using/building an app

- Regarding the mention above about rewriting the project to be more modular/flexible for developers, I felt doing this was 100% necessary/worth it because it occurred to me a few months ago that the best approach to make this succeed in the long term is to make this a legitimate platform (buzzword, sorry!) where developers can quickly/easily make and share awesome extensions and be rewarded (paid) for their work

Check it out (sign up for it ;) here and remember to ignore the bad, vague descriptions currently on the site: http://loggur.com

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#35

The Pipes/IFTTT concept screams for a more open solution, it's too important to be proprietary. I'm always frustrated when I want to use IFTTT but they don't support the services I need. A simple protocol based on HTTP, JSON, and WebHooks could be pretty slick.

My memory is fuzzy about this but IIRC some folks from the Gnome Conduit project launched or talked about launching a web version of it. Not sure though.

Sadly, the project seems dormant. Could be an interesting starting point anyway.

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#37
post #34

The Pipes/IFTTT concept screams for a more open solution, it's too important to be proprietary. I'm always frustrated when I want to use IFTTT but they don't support the services I need. A simple protocol based on HTTP, JSON, and WebHooks could be pretty slick.

I've actually been working on exactly this (but considerably more powerful and in-depth than Pipes/IFTTT) for quite some time now (almost 2 years, on and off). It was originally designed to appeal to non-programmers; and I would have released it months ago but decided to rewrite nearly everything to make the code as modular/flexible/easy-to-learn as possible for developers (both newbie and seasoned). Before I link to…

Sounds interesting. I'll give it a try asap you release it.

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#38
i've been a pipes user for many years. i mainly use it as a way to merge RSS feeds into a single bucket (e.g. craigslist items within 50 miles across multiple craigslists). my most frequently used pipe marries a bunch of news sources together by company name, a simple way to keep track of my industry and competitors.

i live in constant worry that yahoo will shut it down. glad to see it's getting some attention, and getting some clones, too.

Re: The Forgotten Yahoo Project That Inspired Two Recently Funded Startups

#39

The problem with Yahoo Pipes was that it was over-optimized for complex dataflows. It was possible to do things like "find all Flickr photos from user, filter by tag and display on a map by location taken". The result was this crazy programming GUI that resembled Labview. In practice, few people needed such complex querying and chaining. I think IFTT has a better metaphor ("if this, then that") which is much simpler…

> this crazy programming GUI that resembled Labview

Visual programming is a guarantee of failure, unless your target users are electrical engineers. Fact.

Post reply on HN