Many of you rely on feedly to discover the content that matters to you – the gems that help accelerate your research, marketing and sales. We just rolled out a new version of feedly Pro which lets you do more with your content.
Notes and Highlights
Reading shapes what you know, who you are, and how you think. Reading is your silent teacher and mentor. With the new highlights feature, you can easily save the magic moments when you connect to new ideas – and come back to them more easily.
Notes and highlights are available on the Web today and will be rolling out next week on iOS and Android.
If you are not interested in using the new notes feature and would like to save the space at the top of your stories, there is a preference knob in your preferences page to turn this feature off.
Better WordPress Integration
If part of your workflow is saving excerpts of the best stories you discover in your feedly to one of your WordPress blogs, the new feedly Pro will save you a lot of time.
Simply click on the WordPress icon in the share toolbar and feedly will launch the WordPress PressIt window with the story you are reading. Quickly pick a picture, a category, or a tag, add your point of view and click on publish!
You can also personalize the excerpt that gets associated with the story by selecting a snippet of text before clicking on the WordPress icon.
WordPress is continuously improving their PressIt feature so we highly recommend upgrading to WordPress 4 if you want to benefit from the latest improvements.
IFTTT and Zapier
The new feedly Pro also includes a better integration with IFTTT and Zapier. This new version integrates with those platforms in real-time. For example, as soon as a story is saved to one of your personal knowledge boards (the new name for tags), all the recipes and zaps which are bound to that event are fired in real-time. We also improved the logic for image selection for recipes which require an image.
Faster Experience
We are working continuously behind the scenes to optimize feedly and add the hardware needed to keep feedly fast and boost your productivity. Here is a blog post about the performance optimizations we are currently working on.
Thank You!
Thank you for your backing: we are very grateful to be funded by our customers and to control our destiny.
Earlier this year, the feedly cloud had a rough patch: API requests and feed updates started slowing down, eventually reaching the point where we experienced outages for a few days during our busiest time of the day (weekday mornings). For a cloud based company, being down for any period of time is soul-crushing never mind for a few mornings in a row. This led to a lot of frustration, late nights, and general questioning of the order of the universe. But with some persistence we managed to get through it and figure out the problem. We thought it may be some combination of instructive and interesting for others to hear, so we’re sharing the story.
But first we’d especially like to thank Lars George. Lars is a central figure in the HBase community who has now founded a consulting company, OpenCore. It’s essentially impossible to find a great consultant in these situations, but through a bit of luck Lars happened to be in the Bay Area during this period and stopped by our offices for a few days to help out. His deep understanding of the HBase source code as well as past experiences was pivotal in diagnosing the problem.
The Cloud Distilled
Boiled down to basics, the feedly cloud does 2 things, downloads new articles from websites (which we call “polling”) and serve API requests so users can read articles via our website, mobile apps, and even third party applications like reeder. This sounds simple, and in some sense it is. Where it gets complex is the scale at which our system operates. On the polling side, there are about 40 million sources producing over 1000 articles every second. On the API side, we have about 10 million users generating over 200 million API requests per day. That’s a whole lotta bytes flowing through the system.
the main components of the cloud
Due to this amount of data, the feedly cloud has grown significantly over the last 3 years: crawling more feeds, serving more users, and archiving more historical content – to allow users to search, go back in time, and dig deeper into topics.
Another source of complexity is openness. As a co-founder, this is one aspect of feedly that I really love. We allow essentially any website to be able to connect with any user. We also allow 3rd party apps to use our API in their application. As an engineer, this can cause lots of headaches. Sourcing article data from other websites leads to all kinds of strange edge cases — 50MB articles, weird/incorrect character encodings, etc. And 3rd party apps can generate strange/inefficient access patterns.
Both of these factors combine to make performance problems particularly hard to diagnose.
What Happened
We experienced degraded performance during the week of April 10th and more severe outages the following week. It was fairly easy to narrow the problem down to our database (HBase). In fact, In the weeks prior, we noticed occasional ‘blips’ in performance and during those blips a slowdown in database operations, albeit on a much smaller scale.
The feedly cloud was not so happy that week, my friends.
Fortunately our ops team had already been collecting hbase metrics into a graphing system. I can’t emphasize how important this was. Without any historical information, we’d be at a total loss as to what had changed in the system. After poking around the many, many, many HBase metrics we found something that looked off (the “fsSyncLatencyAvgTime” metric). Better still, these anomalies roughly lined up with our down times. This led us to come up with a few theories:
We were writing larger values. This could occur if user or article data changed somehow or due to a buggy code change.
We were writing more data overall. Perhaps some new features we built were overwhelming HBase.
Some hardware problem.
We hit some kind of system limit in HBase and things were slowing down due to the amount or structure of our data.
Unfortunately all these theories are extremely hard to prove or disprove, and each team member has his own personal favorite. This is where Lars’s experience really helped. After reviewing the graphs, he dismissed the “system limit” theory. Our cluster is much smaller than some other companies out there and the configuration seemed sane. His feeling was it was a hardware/networking issue, but there was no clear indicator.
Theory 1: Writing Larger Values
This theory was kind of a long shot. The idea is that perhaps every so often we were writing really big values and that caused hbase to have issues. We added more metrics (this is a common theme when performance problems hit) to track when outlier read/write sizes occur, e.g. if we read or wrote a value larger than 5MB. After examining the charts, large read/writes kind of lined up with slowdowns but not really. To eliminate this as a possibility, we added an option to reject any large read/writes in our code. This wouldn’t be a final solution — all you oddballs that subscribe to 20,000 sources wouldn’t be able to access your feedly — but it let us confirm that this was not the root cause as we continued to have problems.
Theory 2: Writing More Data
This theory was perhaps more plausible than theory 1. The idea was that as feedly is growing, we eventually just reached a point where our request volume was too much for our database cluster to handle. We again added some metrics to track overall data read and write rates to hbase. Here again, things kind of lined up but not really. But we noticed we had high write volume on our analytics data table. This table contains a lot of valuable information for us, but we decided to disable all read/write activity to it as it’s not system critical.
After deploying the change, things got much better! Hour long outages were reduced to a few small blips. But this didn’t sit well with us. Our cluster is pretty sizable, and should be able to handle our request load. Also, the rate of increase in downtime was way faster than our increase in storage used or request rate. So we left the analytics table disabled to keep performance manageable but continued the hunt.
Theory 3: Hardware Problem
As a software engineer this is always my favorite theory. It generally means I’ve done nothing wrong and don’t have to do anything to fix the problem. Unfortunately hardware fails in a myriad of oddball ways, so it can be very hard to convince everyone this is the cause and more importantly to identify the failing piece of equipment. This ended up being the root cause, but was particularly hard to pin down in this case.
How we Found the Problem and Fixed it
Here again, Lars’s experience helped us out. He recommended isolating the HBase code where the problem surfaced and then creating a reproducible test by running it in a standalone manner. So after about a day of work I was able to build a test we could run on our database machines, but independent of our production data. And it reproduced the problem! When debugging intermittent issues, having a reproducible test case is 90% of the battle. I was able to enable all the database log messages during the test and I noticed 2 machines were always involved in operations when slowdowns occurred, dn1 and dn3.
I then extended the test to separately simulate the networking and disk write behavior the HBase code performed. This let us narrow down the problem down to a network issue. We removed the 2 nodes from our production cluster and things immediately got better. Our ops team found out the problem was actually in a network cable or patch panel. This was an especially insidious failure as it didn’t manifest itself in any machine logs. Incidentally, network issues was actually Lars’s original guess as to the problem!
The metric in question when we fixed the problem. Notice the immediate change in behavior.
Lessons Learned
The important thing when dealing with performance problems (outside of, you know, fixing them) is trying to learn what you did well and what you could have done better.
Things we did well:
Have a good metrics collection/graphing system in place. This should go without saying, but lots of times these types of projects can get delayed or deferred.
Get expert help. There’s lots of great resources out there. If you can’t find a great consultant, lots of people are generally willing to help on message boards or other places.
Stayed focused/methodical. It can get crazy when things are going wrong, but having a scientific process and logical way to attack the problem can make things manageable.
Dig into our tech stack. We rely almost exclusively on open source software. This enabled us to really understand and debug what was going on.
Things we could have done better:
Communicate. While Lars suggested networking, I initially discounted it since the problem manifested everywhere in our system, not just one machine. I would have learned there are some shared resources specific to data center build outs.
Gone more quickly to the hardware possibility. We did a lot of google searching for the symptoms we were seeing in our system, but there was not much out there. This is kind of an indicator something weird is probably happening in your environment. A hardware issue is pretty likely.
Attacked the problem earlier. As I mentioned, we had seen small blips prior to the outages and even done some (mostly unproductive) diagnostic work. Unfortunately not giving this top priority came back to bite us.
The feedly cloud today, hardy and hale.
But there’s a happy ending to this story. As this post hopefully demonstrates, we’ve learned a lot and came out stronger: the feedly cloud is faster than ever and we have a much better understanding of the inner workings of HBase. We realize speed is very important to our users and will continue to invest in making the feedly Cloud faster and more resilient. Speaking of resilience, though we had a small downturn in feedly pro signups in April, we are back to normal. This speaks to what a great community we have!
Earlier this year, the feedly cloud had a rough patch: API requests and feed updates started slowing down, eventually reaching the point where we experienced outages for a few days during our busiest time of the day (weekday mornings). For a cloud based company, being down for any period of time is soul-crushing never mind for a few mornings in a row. This led to a lot of frustration, late nights, and general questioning of the order of the universe. But with some persistence we managed to get through it and figure out the problem. We thought it may be some combination of instructive and interesting for others to hear, so we’re sharing the story.
But first we’d especially like to thank Lars George. Lars is a central figure in the HBase community who has now founded a consulting company, OpenCore. It’s essentially impossible to find a great consultant in these situations, but through a bit of luck Lars happened to be in the Bay Area during this period and stopped by our offices for a few days to help out. His deep understanding of the HBase source code as well as past experiences was pivotal in diagnosing the problem.
The Cloud Distilled
Boiled down to basics, the feedly cloud does 2 things, downloads new articles from websites (which we call “polling”) and serve API requests so users can read articles via our website, mobile apps, and even third party applications like reeder. This sounds simple, and in some sense it is. Where it gets complex is the scale at which our system operates. On the polling side, there are about 40 million sources producing over 1000 articles every second. On the API side, we have about 10 million users generating over 200 million API requests per day. That’s a whole lotta bytes flowing through the system.
the main components of the cloud
Due to this amount of data, the feedly cloud has grown significantly over the last 3 years: crawling more feeds, serving more users, and archiving more historical content – to allow users to search, go back in time, and dig deeper into topics.
Another source of complexity is openness. As a co-founder, this is one aspect of feedly that I really love. We allow essentially any website to be able to connect with any user. We also allow 3rd party apps to use our API in their application. As an engineer, this can cause lots of headaches. Sourcing article data from other websites leads to all kinds of strange edge cases — 50MB articles, weird/incorrect character encodings, etc. And 3rd party apps can generate strange/inefficient access patterns.
Both of these factors combine to make performance problems particularly hard to diagnose.
What Happened
We experienced degraded performance during the week of April 10th and more severe outages the following week. It was fairly easy to narrow the problem down to our database (HBase). In fact, In the weeks prior, we noticed occasional ‘blips’ in performance and during those blips a slowdown in database operations, albeit on a much smaller scale.
The feedly cloud was not so happy that week, my friends.
Fortunately our ops team had already been collecting hbase metrics into a graphing system. I can’t emphasize how important this was. Without any historical information, we’d be at a total loss as to what had changed in the system. After poking around the many, many, many HBase metrics we found something that looked off (the “fsSyncLatencyAvgTime” metric). Better still, these anomalies roughly lined up with our down times. This led us to come up with a few theories:
We were writing larger values. This could occur if user or article data changed somehow or due to a buggy code change.
We were writing more data overall. Perhaps some new features we built were overwhelming HBase.
Some hardware problem.
We hit some kind of system limit in HBase and things were slowing down due to the amount or structure of our data.
Unfortunately all these theories are extremely hard to prove or disprove, and each team member has his own personal favorite. This is where Lars’s experience really helped. After reviewing the graphs, he dismissed the “system limit” theory. Our cluster is much smaller than some other companies out there and the configuration seemed sane. His feeling was it was a hardware/networking issue, but there was no clear indicator.
Theory 1: Writing Larger Values
This theory was kind of a long shot. The idea is that perhaps every so often we were writing really big values and that caused hbase to have issues. We added more metrics (this is a common theme when performance problems hit) to track when outlier read/write sizes occur, e.g. if we read or wrote a value larger than 5MB. After examining the charts, large read/writes kind of lined up with slowdowns but not really. To eliminate this as a possibility, we added an option to reject any large read/writes in our code. This wouldn’t be a final solution — all you oddballs that subscribe to 20,000 sources wouldn’t be able to access your feedly — but it let us confirm that this was not the root cause as we continued to have problems.
Theory 2: Writing More Data
This theory was perhaps more plausible than theory 1. The idea was that as feedly is growing, we eventually just reached a point where our request volume was too much for our database cluster to handle. We again added some metrics to track overall data read and write rates to hbase. Here again, things kind of lined up but not really. But we noticed we had high write volume on our analytics data table. This table contains a lot of valuable information for us, but we decided to disable all read/write activity to it as it’s not system critical.
After deploying the change, things got much better! Hour long outages were reduced to a few small blips. But this didn’t sit well with us. Our cluster is pretty sizable, and should be able to handle our request load. Also, the rate of increase in downtime was way faster than our increase in storage used or request rate. So we left the analytics table disabled to keep performance manageable but continued the hunt.
Theory 3: Hardware Problem
As a software engineer this is always my favorite theory. It generally means I’ve done nothing wrong and don’t have to do anything to fix the problem. Unfortunately hardware fails in a myriad of oddball ways, so it can be very hard to convince everyone this is the cause and more importantly to identify the failing piece of equipment. This ended up being the root cause, but was particularly hard to pin down in this case.
How we Found the Problem and Fixed it
Here again, Lars’s experience helped us out. He recommended isolating the HBase code where the problem surfaced and then creating a reproducible test by running it in a standalone manner. So after about a day of work I was able to build a test we could run on our database machines, but independent of our production data. And it reproduced the problem! When debugging intermittent issues, having a reproducible test case is 90% of the battle. I was able to enable all the database log messages during the test and I noticed 2 machines were always involved in operations when slowdowns occurred, dn1 and dn3.
I then extended the test to separately simulate the networking and disk write behavior the HBase code performed. This let us narrow down the problem down to a network issue. We removed the 2 nodes from our production cluster and things immediately got better. Our ops team found out the problem was actually in a network cable or patch panel. This was an especially insidious failure as it didn’t manifest itself in any machine logs. Incidentally, network issues was actually Lars’s original guess as to the problem!
The metric in question when we fixed the problem. Notice the immediate change in behavior.
Lessons Learned
The important thing when dealing with performance problems (outside of, you know, fixing them) is trying to learn what you did well and what you could have done better.
Things we did well:
Have a good metrics collection/graphing system in place. This should go without saying, but lots of times these types of projects can get delayed or deferred.
Get expert help. There’s lots of great resources out there. If you can’t find a great consultant, lots of people are generally willing to help on message boards or other places.
Stayed focused/methodical. It can get crazy when things are going wrong, but having a scientific process and logical way to attack the problem can make things manageable.
Dig into our tech stack. We rely almost exclusively on open source software. This enabled us to really understand and debug what was going on.
Things we could have done better:
Communicate. While Lars suggested networking, I initially discounted it since the problem manifested everywhere in our system, not just one machine. I would have learned there are some shared resources specific to data center build outs.
Gone more quickly to the hardware possibility. We did a lot of google searching for the symptoms we were seeing in our system, but there was not much out there. This is kind of an indicator something weird is probably happening in your environment. A hardware issue is pretty likely.
Attacked the problem earlier. As I mentioned, we had seen small blips prior to the outages and even done some (mostly unproductive) diagnostic work. Unfortunately not giving this top priority came back to bite us.
The feedly cloud today, hardy and hale.
But there’s a happy ending to this story. As this post hopefully demonstrates, we’ve learned a lot and came out stronger: the feedly cloud is faster than ever and we have a much better understanding of the inner workings of HBase. We realize speed is very important to our users and will continue to invest in making the feedly Cloud faster and more resilient. Speaking of resilience, though we had a small downturn in feedly pro signups in April, we are back to normal. This speaks to what a great community we have!
Today we passed an exciting new milestone: 60,000 users have subscribed to feedly Pro. We would like to take a moment and thank each one of you and share some of the projects we are working on, thanks to this new funding.
1. More servers – The feedly cloud is connected to 42,000,000 feeds of information, receiving about 50,000,000 new stories every day. We are adding servers to the feedly Cloud to store, organize, and index all of this information so that we can continue to serve you feedly very fast.
2. Feedly login – This is something a lot of users have been requesting for some time. We now have the resources to fund this project and make it a reality. We will continue to offer the ability to log in with Google, Facebook, Twitter, Microsoft, and Evernote to people who prefer to use existing logins. We are also adding support for logging in with Slack and Office 365, since we hear that it will make logging in even easier for some of our users.
3. Shared tags – When we released Shared Collections last month, some users asked us to go one step further and also allow them to share some of their tags. We really like this idea and are working on both continuing to enhance Shared Collections and adding shared tags.
4. Filtering, saved search, and noise reduction – We have been hearing a lot of murmurs from you around the need for filtering and for alerts. We are going to use part of the new Pro funding for a project that will allow you to define manual and automated filters. It will also allow you to save searches as alerts. We love the idea of giving you even more control over how to tailor your feedly. More signal, less noise.
5. Better Slack integration – We think that we can reduce some of the friction that exists around manually sharing stories from your feedly into your Slack channels. Many users are using feedly and Slack in tandem, so we are going to invest some time enhancing the integration.
6. Fewer iOS crashes – We have been receiving some reports of iOS crashes. They seem related to loading web pages, videos, and animated gifs within feedly. We hate crashes as much as anyone else, and we are fixing this. We are investing time into a new update of the feedly iOS application which changes how we load content and minimizes the risk of the application crashing. We are also investing time optimizing how we serve content to minimize battery usage. You should see the fruits of this work in the v30 update of the app which should be available within a few weeks.
7. Team edition – More on that soon…
Thanks to your backing, we’re able to continuously invest in building a better, faster, stronger and more useful work newsfeed. It is a great pleasure to serve you.
Today we passed an exciting new milestone: 60,000 users have subscribed to feedly Pro. We would like to take a moment and thank each one of you and share some of the projects we are working on, thanks to this new funding.
1. More servers – The feedly cloud is connected to 42,000,000 feeds of information, receiving about 50,000,000 new stories every day. We are adding servers to the feedly Cloud to store, organize, and index all of this information so that we can continue to serve you feedly very fast.
2. Feedly login – This is something a lot of users have been requesting for some time. We now have the resources to fund this project and make it a reality. We will continue to offer the ability to log in with Google, Facebook, Twitter, Microsoft, and Evernote to people who prefer to use existing logins. We are also adding support for logging in with Slack and Office 365, since we hear that it will make logging in even easier for some of our users.
3. Shared tags – When we released Shared Collections last month, some users asked us to go one step further and also allow them to share some of their tags. We really like this idea and are working on both continuing to enhance Shared Collections and adding shared tags.
4. Filtering, saved search, and noise reduction – We have been hearing a lot of murmurs from you around the need for filtering and for alerts. We are going to use part of the new Pro funding for a project that will allow you to define manual and automated filters. It will also allow you to save searches as alerts. We love the idea of giving you even more control over how to tailor your feedly. More signal, less noise.
5. Better Slack integration – We think that we can reduce some of the friction that exists around manually sharing stories from your feedly into your Slack channels. Many users are using feedly and Slack in tandem, so we are going to invest some time enhancing the integration.
6. Fewer iOS crashes – We have been receiving some reports of iOS crashes. They seem related to loading web pages, videos, and animated gifs within feedly. We hate crashes as much as anyone else, and we are fixing this. We are investing time into a new update of the feedly iOS application which changes how we load content and minimizes the risk of the application crashing. We are also investing time optimizing how we serve content to minimize battery usage. You should see the fruits of this work in the v30 update of the app which should be available within a few weeks.
7. Team edition – More on that soon…
Thanks to your backing, we’re able to continuously invest in building a better, faster, stronger and more useful work newsfeed. It is a great pleasure to serve you.
At feedly, we believe at our core that knowledge is power, and thus content is empowering—and even more so when you share it!
So we are excited to introduce today a new feedly Pro feature we call Shared Collections—a new and highly requested tool that lets you choose to share what you read with your teammates, colleagues, and followings.
With Shared Collections, you can take the collections of reading sources you’ve already created—or create a new collection for the purpose of sharing—and make them public on one shared collections page dedicated just for you or your team. This Shared Collection page will showcase all of the blogs, publications, YouTube feeds, and Google News Alerts you want to showcase and make it easy for other people to follow the same sources with just a click. It’ll also allow you to create a personalized URL for your Shared Collections (nab the one you want today!).
Take that Shared Collections page and use it to collaborate with others or to show the world what feeds your mind. You can even customize it to fit your company’s identity or your personal brand.
Shared Collections is completely opt-in. All of your collections default to private, so you can make use of this feature only if you want to. When you are ready to share, turn on the collections you want public and keep your personal collections private.
See how ThoughtWorks, a consulting agency in San Francisco, has been using Shared Collections to collaborate across their organization and to scale their content marketing efforts:
Here are a few ways you can use your Shared Collections:
Help your organization all follow the same publications, blogs, YouTube feeds, and Google Alerts. Empower your workforce to read and share.
Lead your industry by curating and sharing a rich list of must-follow reads. Lead others by showing them the important sources in your industry and move everyone forward together.
Help your teammates and peers find the best publications, blogs, YouTube feeds, and Google Alerts to do their jobs and join the conversation. Keep your teammates informed, moving in the same direction, and inspired with new ideas.
Make it easy to promote your company or agency’s thought leadership by putting all of your employees’ blogs and social media in one easy-to-follow branded page. Provide your customers, clients, social media following, and observers with a one-stop shop to find all of the resources created by your company. Perfect for any company in content marketing or with an employee social media program.
Organize your social media curation efforts by getting your team organized with the same sources. Need to feed the Content Monster? Arm your social media team with lots of publications and blogs to find entertaining posts.
Looking for some inspiration? Go to http://feedly.com/i/discover to browse other people’s Collections. Here are just a few we love:
MIT’s Shared Collection page – Get all of MIT’s rich—and often free—resources in one place. Easily browse MIT’s feed by department and add their content to get the latest on what one of the world’s best universities is doing at the forefront of science and technology.
Annie Cushing’s Shared Collection page – Annie, who is a data analytics and SEO expert, uses her Shared Collection page to share interesting sites on a daily basis to her friends and colleagues on social media.
ThoughtWorks’s Shared Collection page – As spotlighted in the video above, ThoughtWorks uses Shared Collections to provide clients resources, to boost internal collaboration and communication, and to stay connected to alumni.
Enjoy the feature! Please try it out and if you make a cool Shared Collection, share it with the feedly community in the comments below and we’ll spotlight our favorites. For more information on making the most of Shared Collections, you can check out the tutorial.
Feedly and Google have been collaborating on integrating feedly into Google Now so that your most important stories surface in your Google Now stream. We recently rolled out this feature in beta and are seeing a high 14% tap-through rate with the feedly cards. We are excited to announce that the feature is now being rolled out to everyone.
Your important stories come to you
We believe reading sparks magic moments when ideas, knowledge, and creativity seamlessly come together. It’s the core reason why we work so hard to make feedly the most efficient way to personalize and read the content that’s important to you.
We spend a lot of time talking to our users, and we know that most of you weave what you read into your everyday life—to get better at what you do, to keep you ahead of what’s going on, to stay inspired, to learn new things, and be productive. We know that the ability to personalize this experience—when and how you get your news—and to integrate it with other services you use is just as important.
Google Now allows you to easily access specific information in the time and place that it’s most useful to you. As we keep expanding the number of integrations available to feedly users, Google Now seemed like a fitting service for our users, so that you can easily have the stories you need the most come to you, without you having to look for it yourself.
With feedly Now cards, feedly will find the trending stories in the publications you follow and surface them to you throughout the day through Google Now. And you can personalize this experience even more: If you have favorite publications or blogs that you’d love to see in Google Now, you can tell us to follow these stories more closely by marking those sources as must-read in your feedly.
For instance, if you are a PR manager in tech, you can mark the top-tier tech blogs as “must read,” so that breaking stories automagically come to you. Or if you are a physician following the latest in, say, pediatrics or infectious diseases, you can mark your favorite journals as must-read, so that the big stories from these favorite sources surface in your Google Now stream.
Turn it on!
To start seeing feedly Now cards, please make sure you have the latest Google app and feedly app installed on your Android device and are logged into feedly.com. Simply tap the blue Google app icon to see your Now cards. You’re good to go!
(You can also opt out by clicking the settings icon next to the feedly Now card in the Google Now app. Go here to learn more about turning off Google Now cards.)
Open Design Contest / Win feedly Pro lifetime
We would love to hear from the feedly community about how we could improve the personalization engine powering this feature and give you more control over which stories should be surfaced in Google Now. Please leave some suggestions by commenting on this blog post, and we’ll pick two of our favorite suggestions, implement them, and offer a lifetime feedly Pro subscription to the lucky people who suggested them!
We’ll use all of your feedback, so that we can iterate quickly on the next version of feedly Now cards, which we plan to push soon.
Today we’re introducing a new feature called collection sharing, which enables you to easily share the sites you read with others.
Over the years, feedly users have curated millions amazing collections of the best sites to read on a myriad of topics, from photography to fashion, travel to home improvement, politics to finance and everything in between. Shared collections will unlock the incredible wealth of knowledge that has been created within those feedly reading lists.
Though feedly will always remain a reader app at its core, collection sharing is part of our larger vision to make reading more collaborative and create a platform for knowledge sharing within feedly. Thousands of users have told us over the past year that having better ways to share would help them at work and at school. In fact, one of the main takeaways from a survey we ran last year about this topic was that feedly readers are enthusiastic about sharing and want more ways to share what they read with friends and co-workers.
We’re building a community of passionate readers and we’ll be inviting users who are excited to share the sites they read and represent the breadth of knowledge available in feedly.
Our plan is to open collection sharing to everyone over the next few months, starting with feedly Pro users, but you can apply now to get early access and view collections from your peers.
Today we’re introducing a new feature called collection sharing, which enables you to easily share the sites you read with others.
Over the years, feedly users have curated millions amazing collections of the best sites to read on a myriad of topics, from photography to fashion, travel to home improvement, politics to finance and everything in between. Shared collections will unlock the incredible wealth of knowledge that has been created within those feedly reading lists.
Though feedly will always remain a reader app at its core, collection sharing is part of our larger vision to make reading more collaborative and create a platform for knowledge sharing within feedly. Thousands of users have told us over the past year that having better ways to share would help them at work and at school. In fact, one of the main takeaways from a survey we ran last year about this topic was that feedly readers are enthusiastic about sharing and want more ways to share what they read with friends and co-workers.
We’re building a community of passionate readers and we’ll be inviting users who are excited to share the sites they read and represent the breadth of knowledge available in feedly.
Our plan is to open collection sharing to everyone over the next few months, starting with feedly Pro users, but you can apply now to get early access and view collections from your peers.
Our popular web browsing companion is officially relaunching today with a brand new user interface and a suite of new features. feedly Mini is a Chrome extension that keeps you connected to your feedly as you browse, allowing you to save, tag, share or subscribe to the great content you find each day.
A big thank you to all the users to participated to the beta program.
feedly Mini should show up on most of the sites you browse allowing you to share, save or subscribe to new content — you can even save articles from sites you’re not already subscribed to. However, feedly Mini has a blacklist of sites where it shouldn’t appear, so you can specify sites on which you don’t want feedly Mini to appear (see Options to edit the blacklist). Feedly Mini will also not appear on sites that use HTTPS (SSL).
Can I disable feedly Mini?
Yes. Click on the feedly mini icon, select the gear option and you will find a checkbox that let’s enable/disable feedly Mini.
Will feedly Mini be available on Firefox or Safari?
feedly Mini is currently available only as an extension for the Chrome web browser. We’re evaluating which other browsers we should support in future releases. Please let us know in the comments below what browsers you use.
Does feedly Mini collect any information about my browsing history?
No. We value your privacy and will not collect any information about the sites you browse while feedly Mini is active.
Why doesn’t feedly Mini work on HTTPS pages?
We are just being extra cautious: we do not want to interfere with HTTPS pages and we do not want users to grant us access to HTTPS pages.
