Your comments
Hi Steven,
We have the software capability to build a "like" button (just for BLOX though; this is separate from Facebook and could be presented much differently) that could be used in a similar way. Users would be able to "vote" on their favorite businesses, and we would be able to provide a count of how many likes a business got, and a block to show businesses by count, and so forth. (Much like this site!)
There are some schools of thought that a single increment button is more "positive" because you can only vote up the business... rather than providing a one-star rating which can be very negative.
What do you think? Could something like that be an option, or do you feel stars are required?
We have the software capability to build a "like" button (just for BLOX though; this is separate from Facebook and could be presented much differently) that could be used in a similar way. Users would be able to "vote" on their favorite businesses, and we would be able to provide a count of how many likes a business got, and a block to show businesses by count, and so forth. (Much like this site!)
There are some schools of thought that a single increment button is more "positive" because you can only vote up the business... rather than providing a one-star rating which can be very negative.
What do you think? Could something like that be an option, or do you feel stars are required?
If you check "disabled" on all of the services, then your site will be 'free' and no one will see the subscription options or the paywall. Then you can remove that flag later (to re-enable the services) and not have to re-select all the URLs.
You could also remove very specific URLs (but un-selecting those, of course).
And, lastly, it is possible to remove subscription from a specific article by going to Other -> Custom Properties and adding a custom property of subscription_bypass = true. Right now that only works with hard paywalls (not metering). We're adding metering bypass options in the next week or so.
You could also remove very specific URLs (but un-selecting those, of course).
And, lastly, it is possible to remove subscription from a specific article by going to Other -> Custom Properties and adding a custom property of subscription_bypass = true. Right now that only works with hard paywalls (not metering). We're adding metering bypass options in the next week or so.
Hi Mike! We're working towards a similar long-term goal - having more integrated documentation - but we're actually trying to remove much of the need to have a separate documentation site, and instead incorporate more inline documentation and help options. (In other words, instead of making it easier to link off to the doc site, we want to bring the docs into the admin!)
This is a long term project that we've started, but again, will take some time to complete.
There are a few different tasks here that are part of this overall effort:
Inline documentation for blocks and skins: A lot of the need for the docs site is to look up values and names for custom properties. As I said before, our intention is to have all of these options eventually coded inline into the template set up itself, with proper explanation and inline documentation.
Block examples: Another use of the documentation site is to see what the blocks look like in action. The "template selector" page in docs is one of our most viewed pages! =) We tried to improve this with the template preview schematics (screenshot below), which can help you choose blocks when you're creating them. We're also looking at ways of providing more detail here as well (perhaps more realistic popup detail images).
Help panels: We've implemented searchable help panels in the Template Editor for some users already. We envision this being available in other applications as well. So, for example, you'd have a help panel in editorial that would allow you to search various docs relating to editorial content.
Again, this is a long-term project, but we've already taken many steps in this direction.
Let me know what you think!
Christine
This is a long term project that we've started, but again, will take some time to complete.
There are a few different tasks here that are part of this overall effort:
Inline documentation for blocks and skins: A lot of the need for the docs site is to look up values and names for custom properties. As I said before, our intention is to have all of these options eventually coded inline into the template set up itself, with proper explanation and inline documentation.
Block examples: Another use of the documentation site is to see what the blocks look like in action. The "template selector" page in docs is one of our most viewed pages! =) We tried to improve this with the template preview schematics (screenshot below), which can help you choose blocks when you're creating them. We're also looking at ways of providing more detail here as well (perhaps more realistic popup detail images).
Help panels: We've implemented searchable help panels in the Template Editor for some users already. We envision this being available in other applications as well. So, for example, you'd have a help panel in editorial that would allow you to search various docs relating to editorial content.
Again, this is a long-term project, but we've already taken many steps in this direction.
Let me know what you think!
Christine
Right... if we did this, there would be some kind of switch to say you wanted to use Google DFP. I think it would need to be on an ad region level rather than global, however... because you have to pay for Google DFP, it seems some sites want to have SOME ads served through Ad Manager (for marketing and promotions, for example) and others through Google DFP.
We CAN serve the DFP JS through the Ad Manager slots (and we've set this up for many sites that have requested it), but we were thinking that external ads already slow down sites as it is, and we thought it would be cleaner to load the DFP code directly, rather than loading one ad system through another ad system (which then sometimes triggers another ad somewhere else, etc.)
The main sticking point for us thus far has been how to set up the positions/sections/slots. In our experience, we have seen a lot of variation in how different newspapers implement this. We would likely choose one model and require that it be used in order to use our implementation.
Let me know what you think! And, if anyone else has any thoughts/suggestions, feel free to jump in!
We CAN serve the DFP JS through the Ad Manager slots (and we've set this up for many sites that have requested it), but we were thinking that external ads already slow down sites as it is, and we thought it would be cleaner to load the DFP code directly, rather than loading one ad system through another ad system (which then sometimes triggers another ad somewhere else, etc.)
The main sticking point for us thus far has been how to set up the positions/sections/slots. In our experience, we have seen a lot of variation in how different newspapers implement this. We would likely choose one model and require that it be used in order to use our implementation.
Let me know what you think! And, if anyone else has any thoughts/suggestions, feel free to jump in!
Hi Chris! Long time; no see! I hope you're doing well. =)
There is some discussion about Google DFP... we have a lot of customers using it, and are doing very well.
One issue that we're talking about is - if we were to integrate this into BLOX - how it would be set up... i.e. the structure of the sections, the positions, and so forth. All of that would need to be unified across all the papers using it, and there are many different ways to use it.
I'm curious to see how many others might be interested in a built-in Google DFP set up? If you would also consider using this, please vote up this post!
What features would you like to see?
Christine
There is some discussion about Google DFP... we have a lot of customers using it, and are doing very well.
One issue that we're talking about is - if we were to integrate this into BLOX - how it would be set up... i.e. the structure of the sections, the positions, and so forth. All of that would need to be unified across all the papers using it, and there are many different ways to use it.
I'm curious to see how many others might be interested in a built-in Google DFP set up? If you would also consider using this, please vote up this post!
What features would you like to see?
Christine
Please note that Part III is tomorrow at 10:30 AM CST! =)
Hi Mike!
Funny you mentioned this, because we actually released software last night that provides some big improvements in this area. =)
Essentially, each template needs to be updated to utilize this new capability. Unfortunately, some of the skins and blocks are so complex that it is very difficult to covert them to the new method (while having them grandfather in current settings).
So, all of the new templates that we create use this new methodology, as well as any templates that could be migrated without migration issues. For example, the Touch 5 templates (both the skin URL properties as well as the block), now look like this:
That screenshot shows the "button icon" list property expanded, with all of its possible choices.
No longer will you have to memorize vague properties and obscure values!
No longer will you be stuck in a tiny table window that doesn't expand!
These new properties also have built-in documentation that explain the nature of the property itself.
In the screenshot above (for a Touch 5 block), you can see the tool tip popover when you hover over the property.
Last night's upgrade also added the ability to do multi-line properties (for blocks of text) and hex color values. These will be rolled out in existing templates (where the new capabilities currently exist) over the next few weeks, where appropriate.
Let me know what you think! Thanks again for your input!
Christine
Funny you mentioned this, because we actually released software last night that provides some big improvements in this area. =)
Essentially, each template needs to be updated to utilize this new capability. Unfortunately, some of the skins and blocks are so complex that it is very difficult to covert them to the new method (while having them grandfather in current settings).
So, all of the new templates that we create use this new methodology, as well as any templates that could be migrated without migration issues. For example, the Touch 5 templates (both the skin URL properties as well as the block), now look like this:
That screenshot shows the "button icon" list property expanded, with all of its possible choices.
No longer will you have to memorize vague properties and obscure values!
No longer will you be stuck in a tiny table window that doesn't expand!
These new properties also have built-in documentation that explain the nature of the property itself.
In the screenshot above (for a Touch 5 block), you can see the tool tip popover when you hover over the property.
Last night's upgrade also added the ability to do multi-line properties (for blocks of text) and hex color values. These will be rolled out in existing templates (where the new capabilities currently exist) over the next few weeks, where appropriate.
Let me know what you think! Thanks again for your input!
Christine
Customer support service by UserEcho
