Closed Mikey1993 closed 2 years ago
"Advanced users"
That's why I created this setting, so that I don't have to cram in features to hold a minority of users by the hand all the time. Advanced users don't like those "hold-by-the-hand" features to get in the way, that's how I see it.
The top button is to refresh the drop list. Apparently some users may have 100s of tabs, and auto-refreshing that selector could be costly in such cases. So I let the user refresh it themselves. The position of the refresh button must count as a good hint I would think.
How costly is it to update 100s of tabs? On my system I don't see any delay, and I have about 50 opened tabs when hitting the reload button. If it's near the 1 second mark on average systems, I think it's better for this to be updated in real time as well, because the perceived delay is a negligible compared to the total time of the task you originally planned to do on the statistics page (which is, of course, to monitor the net requests).
If this is not the case, maybe a way to mitigate this, is to have a check box near the tabs drop down list that says "update tab list in real time", which will be unchecked by default. If a user decides to check it, the reload button will disappear, and vice versa.
The real issue IMO, is that some users will eventually hit the wrong reload button, no matter how advanced they are, and there is a simple way of eliminating this visual imparity by a more clever way of approaching this.
What is your opinion?
On my system I don't see any delay
This is the argument that I hear a bit too often that I have to admit irritates me a lot, so allow me to rant a bit:
<rant>
It's when one dev starts seeing things like this that one dev ends up creating bloated inefficient software. My whole approach is to not dismiss worries about performance. Maybe it will all be fine, may be not. This is how it works: in doubt, expect the worst.
I see terribly inefficient coding from other blockers, and to me it just look like this was the mindset: "pfff I don't see any delay on my system", or "bah, fast enough in my 3-second test". Add up all these "pfff" and "bah", and you end up with poorly performing blockers.
I started developing this thing on a 8 year-old laptop, and with such piece of crap hardware, you do not dismiss performance worries. Just yesterday I learned someone is using uMatrix/uBlock on 2003 hardware. This make me want to go back and do even more thorough code review to identify more performance improvement opportunity (no doubt there are more), not dismiss performance worries based on feelings.
Benchmarks > "bah looks ok to me". Until benchmarks support there are no performance problem to worry about, I play safe and assume there are.
</rant>
Meanwhile, refreshing manually is no big deal, and if you can identify a replacement icon in the FontAwesome set in order to avoid confusion, I am willing to change it. I want to keep as much space as possible in the top bar for nice things like filtering fields, so ithis will have to be a single icon.
Edit: I will look to improve the tab collecting information code first, then maybe auto-refreshing may become more of an option. But right now it's not.
I am truly sorry that my words irritated you, but I really just wanted to share my personal experience that I am currently having, and not to dismiss the importance of performance, or imply that because it works fast on my configuration, it's gonna work like that on others.
Unfortunately, I currently don't have the technical knowledge to do benchmark of the process of reloading the tabs on different machines reliably, but I would definitely would like to! (I think that everyone would like to have this kind of data while developing for this kind of decision in the process of development)
Regarding the replacement of the icon, unfortunately I couldn't find anything that would fit other than the current icon (there is only 1 true "refresh" icon).
I still think this will bring some "Oh, crap" moments to some users, and I understand that the solution is debateable.
The selector actually auto-refresh in uMatrix. I learned afterward that some users may have a 100 tab open, so I became worried about the overhead.
Currently the big overhead I apprehend is that I fetch all the tabs from the chrome API for the sole purpose of getting the title of the page.
I could cache that title when the tab is loaded (I believe it is available for me anyways at one point for free), and in such case, this would remove the worries I have about performance, as all the information I need for the page selector would be all ready to be used.
Yes, this sounds good. I think that this is the best balance of functionality and performance.
One could accidentally erase his process on a page (or ,say, a game) by hitting the wrong "reload button" on the statistics page (clicking the page reloading button instead of the statistics reload top one) There are no tooltips whatsoever, but even if there were, one could be mislead.
A thought: Isn't the top statistics reload button is even needed now that the statistics are initiated only by an explicit user request and are updating in real time?