This is on our roadmap for Notifier!
We are considering something like this, but it comes at this idea in another way...
We are thinking of a "dynamic" collection, where essentially you create a new asset and as part of the asset you define a search query - so it could be populated by slugs, keywords, tags, priorities, or any important parameter.
Then, on the front end, it can still display as a gallery, but essentially it is a search that just keeps populating with those results.
Nice things about this:
1. There is no upper limit, so you could have thousands of assets which are relevant to the gallery.
2. It would be lazy loaded, so, again, it could be infinite. A user would read the most recent things first (or whatever sort priority you decided to use) and then keep traveling back in time.
3. It could grow over time, so you could have something like "prepsports" or "lion attacks" and each time you posted something that qualified, it would automatically show up.
4. Since it is search based, it would not cause performance issues when you are loading thousands of assets at once.
5. In theory (I just thought of this so I'm not 100% sure we could do it) you could have an article search for dynamic galleries that are related by keyword, and automatically show those articles as cards on a story.
6. The gallery would automatically use the first child as the preview image, or you could define a teaser image specific to that gallery which doesn't change.
At the same time, we are considering adding an upper limit to standard photo galleries to ensure they are more efficient. I think as long as we had the dynamic gallery, a limitation to regular galleries is fine. Do you guys agree? Like a 100 image limit for new galleries, existing galleries would be unaffected. Regular galleries would be used for short, specific stories that should be closed after a time. Dynamic galleries would be open and ongoing.
Let me know what you think of this idea and you can help flesh out the requirements. =)
We are just about to launch an integration with a different vendor, but they provide programmatic email ads for BLOX Email Reach.
Due to the multiple "phases" that an email goes through (from us, to our email vendor, to the email software) there are many parts that all need to work in harmony - so this was a somewhat difficult integration to pull off.
That being said, we are doing beta tests this month, and hope to launch in the next few weeks. As part of the program, you get several blocks with different ad sizes, and you just use them throughout your newsletters as you see fit.
I will respond to your CRM ticket if you would like more information.
If anyone else is interested in beta testing, let your sales rep know - we can probably take one or two more. Otherwise, be on the look out for more information as this program launches in a few weeks. =)
Hmmm... I wonder if the reset start time setting should ignore future dates? It is meant to "fix" dates that are a few days old due to a reporter creating the asset two days before and not updating the date.
Hi Greg! I would submit a ticket to our CRM job system. As Robert said, you can get a few of them with exports, or we may be able to look at a job or something else, depending on your needs.
Jason, we're going to treat this as a bug for now... Can you submit a CRM ticket with an example of an asset that didn't get posted, if you have one? I would like to see the domain set up and so forth.
As a side note, we do have a setting now to "reset start time" as part of a workflow change. So, when the article goes live, you can reset the start time to now, and this may actually fix the issue (we'll need to test that), but it may be desired behavior on your side anyway, regardless of whether or not it fixes the issue.
That way, the article start time reflects the actual time it went online, rather then when the reported started working on it.
Are you guys using workflows? Does the start time of the asset pass before the the publish setting is enabled?
Are you sure they aren't hitting "save as draft"? "Save as draft" will do what you say (saving it as a draft until it is published - even if the story goes live). "Save and send" will send it as soon as possible, which would be when the story goes live.
I will do some testing of this to confirm the above behavior... if it is not doing that I would agree it is a bug.
Customer support service by UserEcho