[docs] Improve ad display #21246
[docs] Improve ad display #21246
Conversation
Details of bundle changes.Comparing: f9b581e...2209c6a Details of page changes
|
oliviertassinari
force-pushed
the
docs-improve-ad-display
branch
from
adc9469
to
9acede6
Compare
You already know my opinion about this... |
@mbrookes In the current configuration, it impacts 3 pages: autocomplete, textfield, tabs. I wouldn't expect it to break the flow of reading, as displayed after a demo. Imagine we break down this pages into smaller ones because too large. How would the result be different? What's your concern? I think that this article is interesting:
We need to keep browsing the documentation an enjoyable experience, it's more important. I think that we could/should monitor the number of demos open and the duration of the session metrics to have an idea of the negative impact and eventually correct the approach. There is something that I wonder about. If you check the usage of the ads on major (huge traffic) developers and the designers website, you will find an ad on the "long tail" of the content "consumed".
I wonder if we shouldn't consider our demo details as this "long tail". There are 1m demo interactions per month which could be leveraged into an inline ad when opening a demo:
@levithomason Considering your prior art in this direction, what's your experience with it? |
So nothing lost by not going there...
False equivalence. We wouldn't (I hope) break a page down into smaller parts, just so that we can introduce more advertising.
Granted, but next thing you know, that wasn't impactful enough, and it gets moved after a section; then after a paragraph...
Paywalled |
I didn't see this originally. I'm strongly opposed to it and it seems like you're as well:
|
Ok, we have two core team members opposed to trying ads in the middle of the page, I will remove it.
Agree, the causality is invested. We would break down a page into smaller parts to make it easier to browse. It's not something we have ever done yet (or maybe for the FAB?), but given we will need to break down the page for the date picker and the data grid, I think that we can do it as well with the autocomplete. Sections could be hook vs component, combo box vs multi-select, etc. This would result in more advertising. Usually, you will find the documentation of the existing enterprise UI libraries with multiple pages, for each component. I think that it comes from them having more content and aiming for smaller pages. IMHO tabs and text fields are also almost too long.
Ah, sorry, I was reading it on my phone, I didn't see the paywall. I have asked CodeFund's CEO about his thoughts on the pull request, there is one element that came out looking at the top publishers: inline ad (no image). I think that it's worth trying. I will try to make a second iteration on the pull request by this weekend with the above points. |
oliviertassinari
force-pushed
the
docs-improve-ad-display
branch
from
9acede6
to
2209c6a
Compare
Why
Benchmark