I usually find them unnecessary at best, and distracting at worst. Having the "reading time" listed at the top of the article here is enough to give me a sense of how long the article is. But some people really like having them, so maybe there could be a setting for users to turn it on/off per their personal preferences?

I think the reason I don't care for a generic progress bar is that it doesn't really give me meaningful information about my reading progress. I might be halfway through the text of an article, but how much of the remaining article is code snippets, interactive examples, videos, prose, conclusion, etc? The actual progress of me getting through the article may be massively skewed by things that aren't raw text, and so it tends to feel quite arbitrary, generally-speaking.

A better measure of progress might be to enumerate the Headers in the article content, and highlight progress by which headers I've passed. A good example of this is the right-side menu of theAndroid docs. Seeing that I've got 2 content sections, an example, and a conclusion left until I finish the article ismuch more meaningful than some arbitrary measure of text. In addition, it allows me to skip directly to a specific section on the page.

Comment Not Found

I recently became a technical lead and now I have a team of 2 that I am responsible for. At first, I assumed that I, plus 2 more people meant that we would get 3x as much work done as before and it would be a piece of cake. Oh boy, how wrong I was! Leading a team is HARD WORK! Figuring out exactly how much support each member needs and how to best give it to them while also continuing to technically contribute myself is tough. I have had to accept that contributing less is OK because my time is better spent sharing my knowledge and helping others on my team grow.

TL;DR The hardest part of my job is learning how to effectively lead a team.

CSS

Add the attributesdata-piece1 anddata-piece2 to any element, and it will announce the winner:

[data-piece1][data-piece2]::before{content:attr(data-piece1)' vs 'attr(data-piece2)': ';}/* By default, piece 1 will win */[data-piece1][data-piece2]::after{content:attr(data-piece1)' wins!';}/* Only in some particular cases, piece 2 will win */[data-piece2="archers"i][data-piece1="swordsmen"i]::after,[data-piece2="swordsmen"i][data-piece1="pikemen"i]::after,[data-piece2="pikemen"i][data-piece1="cavalry"i]::after,[data-piece2="cavalry"i][data-piece1="archers"i]::after{content:attr(data-piece2)' wins!'}

InCSS Selectors Level 4, there is an option to make some selectors case-insensitive (adding ani at the end as displayed above). And it is fairly well supported (haven't tried on IE). So it doesn't matter if the user writes "archers" or "Archers" or "aRcHeRs", all of them will be matched.

Comment Not Found