In that post, I discussed how I tried and failed to use my 315L hot water tank as storage for excess energy generated from my solar panels. My problem was that I had a narrow "blockout" time window programmed (starting at 3pm and ending at 11am). During the time window, I have "free" power form my solar panels and, for that reason, I want the system to recharge the tank, thus storing energy that I would have otherwise sold to the grid.
Back to the present. Over the weekend I looked at why my timings did not work. I came across a somewhat dated (2011) Service Technical Manual for the same heat pump model which includes the following description of the logic used to control water heating:
Conditions to start and end heating water are as stated below:
Tank TH A ≤ 45°C (Lack in residual hot water in tank)
More than 24hrs passed since the last start of operation. (for anti-Legionella purpose)
Memory of last operation is lost. (First run after delivery, ROM writing error, etc
Electrical shutdown is occurred while HP unit is operating.
The current time is 10.00 (24hr clock basis).
HP unit was not operated by the condition (5) due to a limitation of HPU operation. HPU operation starts once the limitation is cancelled. The term limitation defines a condition where HPU cannot be operated due to the electricity cutoff or the blockout time setting.
HP unit starts when either of (1), (2), (3), (4), (5) or (6) above is satisfied.
Condition to end, GC Inlet TH > 50°C.
If this logic still holds (the document is dated 2011), then I can't explain why we occasionally went without hot water: conditions 2 and 6 should have ensured tank recharge even if condition 1 was not met.
Nevertheless, I went up the ladder again, unscrewed the four screws, took off the top panel and fiddled and re-enabled blockout, widening the time range by two hours so that the heat pump can run between 10am and 4pm.
For the last two days, our heat pump has come on at exactly 10am.
I have no idea which of the six conditions listed above is being satisfied. But I'll be keeping an eye on the system. With my previous blockout settings, I would expect point 6 to be satisfied and the system to come on at 11am, only it did not seem to.
Not content that I do not understand what's going on, I'm going to perform an experiment and change the system back to 11am through 4pm (best for my solar panels) and check for a regular 11am start.
In summary, the additional information provided in the technical service manual has left me more confused. However, for the present, all appears to be working on a blockout timer and that was my goal.
In a previous post, I made the point that browser reflow is the major issue driving me to the adopt an ad-blocker for my iOS 9 devices. I can live with ads in my content - they are the price I pay for all of that content - but, I cannot live with a page whose content scrolls down out of view after page load.
The (hated) scrolling of content after page load, is, in many cases, the direct result of asynchronous advertisements being inserted into the page. Technologies like ad-blockers and 'Reading Mode' help to alleviate this problem but cause the unfortunate effect of pulling the rug out from under the content provider by blocking their only source of revenue.
In this post I make a suggestion for how a browser might mitigate the problem of reflow.
Reflow
A web browser downloads a document, usually written in HTML. The job of the browser is to translate the HTML, creating a Document Object Model (DOM) describing its content and, from this, a visual representation on a device's screen. In order to draw each letter and each image onto the screen, the browser has to calculate the position of each element in the DOM. This computational step is called reflow.
The DOM of a web page can be modified after it has been loaded; asynchronously, that is. Many web pages include advertisements and these are inserted into the page in different positions, asynchronously and unpredictably.
Asynchronous ad delivery was a big thing when it arrived on the scene in 2010. Fast forward to 2016 and everyone's doing it and doing more of it: both the number and the weight of ads has grown enormously. According to websiteOptimization.com, there has been an exponential increase in both the number and combined size of the objects that are used to display a web page.
The growth of an average web page showed a dramatic rise from 2010 onwards
A direct consequence of the increased number of ads a is decline usability of the content containing the ad.
Reflow is Worse on Mobile
Reflow on mobile creates an awful user experience. Take a look at this video of an iPhone 5 sized screen rendering a page from Forbes with bandwidth throttled to 3G speeds:
I loaded the page and then scrolled down as I read the article. The video begins after I scrolled down and highlights the problems with reflow that occur at about the six and eight second mark: although I did nothing, the paragraph I was reading gets shunted down.
What's going on behind the scenes is that a scripts execute after the page load, creating space in the page for an ad (it modifies the DOM) and then make an asynchronous request for the ad content itself. The space allocated for the ad appears white. The text on the page shunts down and then up as a result of multiple reflow events (as I said earlier, there are many many reasons for reflow).
Here's a before and after view of the page content with blue shading indicating content that is not visible to the user.
In this second image, a script has executed, creating a space for an ad that has not yet arrived over the network. The content I was reading is pushed down and is no longer visible in the viewport.
This scenario is real, is incredibly annoying, is more likely on slower (or rather unpredictable) networks and, is more likely if the display is tall and thin. Reflow is worse on mobile.
Can't We Change the Browser?
Having established that the user experience of reflow is awful, we need to look and see whether there might be a cure. The first place to look is the browser itself. A user story is very simple indeed:
If I scroll the page to view content, then the browser should make all possible efforts to ensure that that content remains visible.
This requirement puts the user experience first and it does not mention reflow - it's just plain common sense. As I write this post, I am tormented by the fact that someone must have thought of this. Why doesn't a browser behave this way already? However, browsers do not handle this situation well.
To implement this, we have to define an anchor point; an element visible in the viewport which is destined to remain visible after reflow. Intuitively, I'd select the element that is at the top-left of the page that has the highest Z-order and is scrollable (assuming an left-to-right language). The anchor element would be updated every time content is scrolled. (R-t-L and vertical writing modes would also have to be accommodated.)
Here's an illustration of my 'anchor' element:
The anchor (red box) is chosen because it is the in the top-left of the viewport after it has been scrolled, does not have a fixed position, is scrollable and has been identified as a 'content element' much as a browser reading mode identifies content elements. Assuming an ad is injected above this anchor element, then the browser would recalculate the height of the content and then align the viewport so that it is in the same position relative to the anchor.
Using a strategy such as this would eliminate a whole class of usability problems caused by content injection and reflow.
I know it Can't be this Simple But...
The strategy currently employed by web browser is to retain the position of the top of the page relative to the viewport and thus when content is injected into the DOM, elements below the new content to shunt downwards.
My suggested strategy is to identify an anchor element that is visible in the viewport before DOM alteration in order to ensure that the element remains visible after DOM alteration. There are many cases where this strategy cannot work. What I'm after is a strategy that improves usability in most cases.
As I said earlier, my sneaking suspicion is that this suggestion is naive. I know that multiple elements on the page can be made scrollable.
I find it hard to believe that this has not been considered by better minds who are closer to the problem than me.
Because "56.1% of all [ad] impressions are not seen, some ads are injected into the visible viewport. (The best placement for an ad is at the bottom of the page or, just "above the fold", in industry speak.) My strategy would not help much in this scenario.
"Content that holds a user's attention has the highest viewability" - a statement that is about ads but is equally applicable to the content containing the ad. It seems to me that, on mobile in particular, asynchronous ad injection circa 2016 degrades "viewabilty" of the content containing the ad because, at worst, it make reading some pages unendurable and, at best, makes the reading experience merely annoying. Perhaps a change in the browser could alleviate some of the usability problems and making the invidious less so?
