Er zijn bepaalde dingen in de computerwereld die ondanks de jaren nooit beter zijn geworden. Bovenaan de lijst staan de printers, historisch problematisch en duur… maar voortgangsbalken staan er niet ver vandaan. Onnauwkeurig, grillig en onbetrouwbaar: voortgangsbalken lijken elke negatieve eigenschap te hebben. Waar komt dat door? Tom Scott legt het uit in een korte video.
We hebben ze allemaal gezien. We kennen al hun varianten. Een balk die van links naar rechts groeit, een percentage-indicator dat oploopt, of een vast aantal megabytes dat moet worden overgezet. Voortgangsbalken hebben al meerdere cosmetische aanpassingen gekregen, maar het onderliggende probleem blijft intact: ze werken gewoon niet zo goed.
Het is natuurlijk niets nieuws of recent. De MS-DOS-gebruikers onder ons herinneren zich die balken die op het scherm leken te bevriezen totdat ze ineens weer tot leven kwamen, en we zullen nooit de "de vijf langste minuten van het universum" vergeten bij het installeren van oude Windows-versies. Dus… wat is er aan de hand? Waarom verhelpen ontwikkelaars dit probleem niet?
Het 'probleem' van voortgangsbalken
Tom Scott legt het prachtig uit in een van zijn video's: de voortgangsbalk is nodig om het werk dat de computer uitvoert (op een bepaalde manier) te visualiseren, maar dat werk is verdeeld in meerdere fasen waarvan de snelheid zonder waarschuwing kan variëren. In tegenstelling tot de voortgangsbalk in een video (die in wezen een enkele taak is), vertegenwoordigt de balk van een programma zaken als het downloaden van bestanden, het decomprimeren ervan, het schrijven naar de opslageenheid en de configuratie van het besturingssysteem.
En daar gaat de precisie door het raam. Het downloaden van bestanden hangt af van hoe snel en/of stabiel de internetverbinding is. De decompressie wordt verzorgd door de geïnstalleerde processor en de hoeveelheid beschikbaar geheugen. De snelheid waarmee bestanden worden geschreven kan enorm verschillen tussen een harde schijf of een SSD, en niet alle besturingssystemen verkeren in de beste staat.
https://old.neoteo.com/por-que-no-puedes-llamar-a-un-archivo-con-en-windows/Populaire alternatieven zoals het tellen van het aantal bestanden of de hoeveelheid megabytes die gekopieerd moeten worden verbeteren de zaken een beetje, maar de voortgang van de balk zal ook niet echt vloeiend zijn. Sommige bestanden zijn van nature groter dan andere, en het kopiëren van veel kleine bestanden kost meer tijd. En over tijd gesproken: een klok met 'seconden resterend' is overgeleverd aan spontane veranderingen in het systeem. Stel je bijvoorbeeld voor dat een programma 60 seconden nodig heeft om een bestand te kopiëren, maar Windows 10 besluit op de achtergrond updates te downloaden. Raad eens wat er met die 60 seconden gebeurt?
Een van de opties die Tom voorstelt is simpelweg het berekenen van een gemiddelde, dat wil zeggen: alles wat het programma in de laatste tien of twintig seconden heeft gedaan als referentie nemen, en daarmee een 'geschatte tijd' opstellen. Zo komen we bij een fundamentele waarheid over balken: ze hoeven niet perfect te zijn of vloeiend vooruit te gaan. Het aangeven van 'voortgang' is voldoende.
