84

Mój infantylny problem z paskami postępu

Zagadnienie jakim jest progress bar irytuje mnie od dawna. Wiem, że nie jest to problem pierwszego świata, ale za każdym razem, kiedy patrzę na tak zwany pasek postępu, czy to w grach czy w aplikacjach, nachodzą mnie pewne przemyślenia. Nie można tego zrobić lepiej? Naprawdę nikt nie umie oszacować, ile czasu będzie trwała dana operacja?

Wiem, że może to być dość osobliwa irytacja, ale zawsze kiedy widzę pasek postępu, który nie przyrasta proporcjonalnie lub kiedy dochodzi do 100% po czym dana operacja, na którą czekamy nadal się nie kończy, myślę sobie WTF?

Pamiętacie Windows 95 (o ile dobrze pamiętam) pasek postępu pokazujący kilkadziesiąt lub kilkaset godzin w zależności od zmian prędkości pobierania jakiegoś pliku? Wtedy dało się to wytłumaczyć, bo na wdzwanianym internecie nigdy nie można było być pewnym szybkości transferu danych. Nie chodzi mi jednak o pasek postępu przy tego typu działaniach. Bardziej o aplikacje i gry. Nie ma dla mnie nic bardziej irytującego niż gapienie się na pasek, który po 2 minutach pokazuje 5% postępu, a następnie wynik ten skacze do 80% i potem stoi tak przez 3 minuty. Patrzę w ten pasek jak zahipnotyzowany i za każdym razem myślę czy naprawdę nie da się tego zrobić lepiej?

Co dokładnie mam na myśl?

Pasek postępu, który pokazuje realny czas oczekiwania. Pasek, którego postęp jest równomierny i możemy przewidzieć za ile czasu dana operacja się skończy – przecież to niemożliwe, aby nie dało się tego wyliczyć. Pasek postępu, który nie oszukuje użytkownika komputera.

Do tego mamy dziś pełną innowacje, jeśli chodzi o wygląd progress barów – natomiast nadal nie działają one tak jak powinny. Najgorsze są jednak te – stosowane głównie w grach – gdzie autorzy już nawet nie próbują oszacować ile czasu potrwa wczytywanie danego levelu i po prostu pokazują kręcące się wiecznie kółko. Jasne, każdy komputer jest inny i trudno z góry przewidzieć czy dany poziom będzie się ładować 2 czy 5 minut. Kiedy jednak już gra jest zainstalowana to przy kolejnym uruchomieniu nie widzę usprawiedliwienia na brak takich szacunków.

Najbardziej jednak irytują mnie paski postępu, które dochodzą do 100% i okazuje się, że to wcale nie jest koniec procesu i czekamy kolejną minutę na to, aby nasz system/gra/program zaczęły reagować i być interaktywne. Tego już zupełnie nie rozumiem. Jeśli developer nie jest w stanie określić czasu uruchomienia programu czy danej operacji to może daruję sobie tworzenie paska postępu.

Nie ważne

Wydaje się, że opracowanie dobrego paska postępu wydaje się mało ważne. Pytanie jednak czy tak jest naprawdę? Nie ma chyba nic gorszego niż zdezorientowany użytkownik oprogramowania, który irytuje się marnując czas patrząc na pasek postępu, który sugeruje, że za chwilę będzie można pracować – kiedy tak naprawdę operacja może potrwać kolejne minuty.

Bardzo ciekawy jestem czy ten moje infantylne przemyślenia są naprawdę tak bardzo błahe czy też “progress bar” jest ważnym zagadnieniem dla developerów? Bardzo chętnie usłyszałbym jakiś komentarz od nich – czy zwracacie na to uwagę, czy też jest to element o najniższym priorytecie?

Ja chcę dobrze działających pasków postępu!!

  • Tre

    Chcę sensownego artu

    • Masz ok 500 miesięcznie – zapraszam do czytania

    • Neliel

      Serio aż tyle wychodzi? Tak na oko wydaje się znacznie mniej.

    • Zależy od miesiąca ale dochodzi do 20 materiałów dziennie czasem

    • Mailosz

      Ale sensownych tak około 25% z tego.

      Bez urazy – wg mnie to i tak dobry wynik.

    • Adam

      Sęk w tym, że idziecie w ilość, nie jakość. Odsłony, odsłony, odsłony. A ja pamiętam Cię z lat 2008-2010, kiedy artów było mało, ale sensowne. O startupach, o rynku web 2.0, nawet o open source. A teraz głównie milion artów o pierdołach w Apple/MS/Google i pojedyncze wieści o innowacjach czy rodzimym rynku IT. Przykład pierwszy z brzegu: ostatnio w Krakowie był międzynarodowy finał Smogathonu – była jakaś relacja, opisy zwycięskich rozwiązań an AW?

      I pierwsze zdanie: „Wiem, że nie jest to problem pierwszego świata” – w takim razie którego?

  • Marcin

    Po pierwsze, mnie też irytuje, chociaż aż tak często już tych pasków nie widzę ;) po drugie, zrobienie realnego paska działającego w różnych aplikacjach, systemach, komputerach i podzespołach idealnie to naprawdę byłaby bardzo skomplikowana sprawa.

    • Bardzo możliwe dlatego chętnie usłyszałbym od developera czy architekta oprogramowania, że się nie da bo się nie opłaca czy coś takiego

    • Marcin

      Właśnie słyszysz ;) w projektach it nigdy nie da się zrobić wszystkiego. Zawsze wybiera się to, co najważniejsze w danej chwili z listy priorytetów. Jeśli ktoś skupiłby się na stworzeniu bardzo dobrego paska postępu (taki pasek trzeba by stworzyć indywidualnie dla każdej aplikacji na świecie, a nie poświęcić chwilę i zrobić gotowca) to później np. przy premierze narzekalibysmy na mniej rozbudowany system, nie wiem, edycji wyglądu postaci albo na poważne bugi w aplikacji. Pasek ładowania, jeśli jak w 99.99% aplikacji jest tylko graficznym elementem upiększającym ekran jednorazowo lub okazyjnie, NIGDY nie będzie wysoko na tej liście.

      PS. Pomijając już fakt, że nawet jakby kazać komuś zrobić taki pasek, to dalej by nie działał idealnie ;D ew. działałby trochę lepiej niż to, co mamy. Jak widzisz, nie ma siły, żeby ktoś to robił.

    • nikt

      Prosty przykład: pasek postępu przy kopiowaniu plików zależy od:
      sytemu plików, typu dysku, zapełnienia dysku, fragmentacji, ilości i wielkości plików. Do tego dochodzą różnego rodzaju bufory i inne optymalizacje, obciążenie systemu przez inne zadania itp. I weź to wszystko ogarnij tylko po to by pasek postępu przesuwał się w równym tempie. (można by operację spowolnić np do 10kB/s wtedy dałoby się utrzymać równe tempo ;P ) A to jest dość przewidywalna operacja, co innego wczytywanie w grach, gdzie masz wczytywanie tekstur, geometrii, dźwięków, skryptów, do tego trzeba trochę policzyć np statyczne cienie, proceduralnie generowane tekstury, mipmapy, układanie obiektów w hierarchię, lub ich sortowanie itp.
      Zamiast pasków postępu mogłyby być kamienie milowe (np: wczytanie tekstur-OK, wczytanie dźwięków-OK, wyliczanie czego popadnie 78%). Wtedy użytkownik uczy się ile co trwa i nie denerwuje się aż tak.

    • MarianMaciag

      Mam jeszcze lepszy i prostszy przykład – pasek postępu podczas przesyłania plików przez sieć, np. internet. Tego w ogóle nie da się oszacować, bo nie masz wpływu na prędkość działania urządzeń, które pracują w sieci (rutery, switche, serwery itp.itd.). Oczywiście możesz przesłać jakiś mały pakiet i na tej podstawie spróbować oszacować czas przesyłu i to dzieje się również dziś w niektórych aplikacjach, ale warunki w sieci zmieniają się tak dynamicznie, że takie szacowanie to bardziej wróżenie z fusów i koniec końców lepiej wyświetlić kręcące się kółko.

    • krzysiekj

      Masz rację i jej nie masz. Tak nie możesz oszacować tego co się za chwile stanie (jedziesz autem i pobierasz coś po LTE, i za chwilę przepniesz się na 2G) – ale to są sytuacje skrajne, nie uważasz? Zwykle pobierasz plik siedząc na pupci w fotelu podpięty do jednego BTS-a lub konkretnego dostawcy, w którym owszem obciążenie sieci może się zmienić jednak znowu – statystycznie w zadanym czasie transfer jest stały (pobierasz plik zwykle w skończonym czasie który jest względnie krótki i jeśli np. liczba użytkowników się zwiększa to nie są to nagłe piki ale raczej rozłożone w czasie zmiany). Inna sprawa jest taka, że sporo ruchu to http/https a ten charakteryzuje się tym, że z punktu widzenia jednego użytkownika to piki – otwierasz nowe zakładki, ale z punktu widzenia 100 użytkowników to w miarę wyrównany jednostajny transfer (nie wszyscy jednocześnie klikają na linki i odpalają kolejne okienka).

      Podobnie wyżej – owszem zależy od dysku, systemu plików itp, itd – ale statystycznie ma 100 uruchomień danej gry/programu warunki w jakich to nastąpiło są identyczne – czyli czas danej operacji jest statystycznie taki sam – o tym Grzesiek pisał.

      It’s only software it can do everything.

    • Marcin

      No i właśnie w tym jest problem – pasek musiałby być unikatowy nie tylko w każdej aplikacji, ale też przy każdym uruchomieniu. A jak sam zauważasz, zawsze będzie różny, a dopiero przy dużej próbie zaczyna się zachowywać „standardowo”

    • Grubas

      Przecież pasek to tylko wizualizacja, a istotne jest jakimi liczbami go karmisz. W tym kontekście każdy progress bar jest indywidualny, gdyż procesy których dotyczy są różne (także w obrębie jednego programu/aplikacji). Natomiast faktem jest, że nakład pracy w komercyjnym sofcie na zrealizowanie dobrego progress bara jest zwykle zbyt duży, gdyż rozchodzi się po prostu o czas, a czas to pieniążki.

      Natomiast co mnie osobiście bardziej wkurza to progress bar, który po dojściu do 100% wraca na 0% i od nowa dąży do 100% (nawet wielokrotnie). To mógłby być antywzorzec UX.

    • krzysiekj

      przy drugiej jest blisko a przy kolejnych coraz bliżej

    • Tomek

      U nas w aplikacji mamy maly priorytet na przedstawienie procentow / przewidywanego czasu wykonania akcji. Wlasciwie wiekszosc paskow sie kreci aby pokazac uzytkownikow tylko informacje, ze aplikacja dziala nad wykonaniem jego akcji.

      Nam po prostu szkoda marnowac zasobow telefonu czy serwera na wykonywanie obliczen na podstawie ktorych mozemy przedstawic procent wykoanania operacji lub szacowany czas do zakonczenia. Biorac pod uwage, ze z aplikacji jednoczesnie moze skorzystac np. tysiac osob to przetworzenie tego typu informacji to marnotrastwo zasobow.

      Nie wiem jak to wyglada u innych ale z tego co ja sie spotkalem pasek postepu to element UI, ktrego zadaniem bylo przekazanie uzytkownikowi informacji, ze strona/apka ‚cos’ robi i aby cierpliwie czekal (glownie zeby user nie pomyslal ze cos sie zacielo).

    • Grubas

      Jeśli proces jest bardziej czasochłonny, a szczególnie gdy jest to proces asynchroniczny, to stosuje się pb. W pozostałych przypadkach wystarczą spinnery.

  • zakius

    to jest niemożliwe
    operacje dyskowe? szybkość pracy HDD w zależności od warunków zmienia się o rzędy wielkości
    złożone obliczenia? wydajność danej architektury, a nawet danego systemu w jednym typie obliczeń nie przekłada się na inny typ
    pobieranie? tutaj zazwyczaj czas jest w miarę sensownie szacowany, ale bywają wahania po drodze

    • akki

      bezproblemowo da sie to zrobic, tylko trzeba chciec, juz po kilku operacja wiadomo jaka jest wydajnosc dysku, jak mocny jest cpu itp itd, majac te dane i znajac swoja appke z dokladnoscia do +-10% jestem w stanie to przewidziec ZAWSZE

    • zakius

      znasz wydajność dysku w danym obszarze, ale kolejna porcja danych będzie pofragmentowana i zejdzie 10x więcej
      jeśli obliczenia się różnią istotnie to też ciężko szacować, tu sam procesor się dusi, a za chwilę utknie na pamięci, później doczyta coś z dysku, zapisze
      można szacować, ale gdy szacunki okazują się odstawać o ponad 50% to nie są zbyt wiele warte

    • Bigos Trismegistos

      Można zaprząc uczenie maszynowe i jeśli dobierze się dobrze dane, którymi je nakarmić (obciążenie CPU, dysku, wszystko co wpływa) – to może dla kopiowania plików by się to udało w dużej ilości przypadków dobrze oszacować. Pytanie czy nie szkoda zasobów na to

    • krzysiekj

      Jakie uczenie maszynowe… z armaty do komara.
      Jeśli masz jakąś sporą gierkę lub program to weź stoper i mierz czas jego uruchomienia za każdym razem np przez tydzień. W większości przypadków nie trzeba zaawansowanej statystyki poza zwykłą średnią arytmetyczną.

    • MarianMaciag

      Tyle, że wydajność dysku zmienia się także w zależności od ilości zajętego miejsca, sposobu ulokowania danych (fragmentacji dysku) czy działania innych procesów, które w tym samym momencie żądają dostępu do dysku. Taka ilość zmiennych powoduje, że dokładność szacunków mocno spada.

    • BloodMan

      Do tego dochodzi coś takiego jak bufory i szybkość ich opróżniania – często to widać przy dyskach USB a jeszcze częściej przy pendrivach. Jest koniec, doleciało do 99% lub 100% i nagle stoi… sttooooooiiii…. i flushuje bufory … i tak minute.
      Nie, nie da się oszacować, bo każdy dysk inaczej – a nawet ten sam dysk inaczej w zależności od tego w jakim jest porcie, czy ‚chwycilo’ USB3, USB2.1 USB2.0 czy USB1.1 – wszystko inaczej :/ Nie da się.

    • krzysiekj

      Tak, tak, bo za każdym razem jak odpalasz daną apkę to tuż przed ta operacją pobrałeś 10 dystrybucji linuxa, a po kilku dniach znowu je usunąłeś i potem znowu pobrałeś. Raz odpalając photoshopa masz odpalone jeszcze 3 przeglądarki i 20 zakładek innym razem nie masz żadnej… itd.
      Nie nie nie – bzdura – jesteśmy przewidywalni, pracując na tym samym sprzęcie dzień po dniu za każdym razem masz sytuację podobną do wcześniejszej, podobne aplikacje, podobna zajętość RAMu, dysku itp.

    • BloodMan

      Super. Myśl tak dalej, i zamknij programistę do specyfiki siebie i swojego sprzętu. Ale masz ego…

    • krzysiekj

      zrób doświadczenie ok? notuj sobie na kartce odpalone programy i co odpalasz kolejno

      dzisiaj większość ludzi usypia kompa, potem go budzi (nawet nie mając tej świadomości) i pracują na puli typowych dla siebie aplikacji – nikogo nie szufladkuje, po prostu widzę jak ludzie używają komputera

    • BloodMan

      Na wstępie – tak między innymi jestem programistą (czyli jak większość, zamiast przyjąć za pewnik to co mówię, zignoruj ciepłym siurem).

      Nie rozumiesz – NIE DA SIĘ zgadnąć, ile np. dysk będzie flushował dane ze SWOJEJ pamięci podręcznej na talerze. Bo nie masz dostępu do tego typu informacji (to wnętrze dysku), bo nie wiesz czy bufory są w 100% pełne czy w 50%, bo nie wiesz jak się ten dysk zachowuje, czy ma gdzieś zator, czy jest pofragmentowany (jak jest pofragmentowany to wolniej zrzuca dane), itd. NIE WIESZ TEGO.
      No chyba że napiszesz progress bar, który przed pokazaniem paska postępu sprawdzi internetową bazę danych dysków (co da mu jakiś pogląd na typową szybkość dysku) oraz przeprowadzi test pofragmentowania dysku – to wtedy MOŻE ci się uda to zrobić dobrze.

      ps. mam pytanie teraz – czy proces sprawdzania w internecie i sprawdzania pofragmentowania dysku też ma mieć progress bar? ;-)
      …bo zaczyna się robić ciekawie…

    • krzysiekj

      >> Na wstępie – tak między innymi jestem programistą

      a ja myślisz kim? jasnowidzem? ;)

      od końca (mało wiesz):
      >> czy proces sprawdzania w internecie

      to tylko przeszukiwanie bazy danych – pojedynczego zapytania nie prześledzisz, natomiast statystycznie wiesz, że zapytanie o ciąg znaków lub kombinacje ciągów (operatory and lub or) zajmuje od X do Y czasu

      >> sprawdzania pofragmentowania dysku też ma mieć progress bar
      po pierwsze primo dzisiaj nie ma sensu odpalać tego typu oprogramowania (linuxowe systemy tego nie potrzebują, pod Windowsem masz SSD, jeśli nie to słabo)

      o tym co piszesz w treści – tak nie da się przewidzieć tego dla pojedynczego procesu na już, ale statycznie po 2, 3 uruchomieniu już wiesz, że średnio to zadanie (np odpalenie Lightrooma, VisualStudio, wirtualki w VirtualBoxie zajmuje X czasu – pisałem Ci notuj sobie, ponoć nic nie przyjmujesz za pewnik).

      Odpal sobie porządnego VPS-a (np. w DO) – tam masz progress bara na tworzenie virtualk, na backup itd. – i to w miarę działa (a to jest dopiero niedeterministyczny proces).

      Jeszcze raz nie wiesz ile będzie Ci się odpalał teraz VisuaStudio, natomiast wiesz, że ostatnio odpalił się w 11s, wcześniej w 10,5s, wcześniej w 13s, wcześniej w 25s itd.. odrzucasz 25s i masz bardzo dobre dane do średniej.
      Statystycznie nie interesuje Cię na jakim poziomie jest w danej chwili bufor dysku itp, bo i tak w większości przypadków te operacje są grube (np duży projekt z Visuala, bogata baza zdjęć w Lightroomie i tak wielokrotnie opróżnią zarówno bufory sprzętowe – te w dysku, jak i programowe – Windowsa czy Linuxa).
      Weź kartkę i notuj, potem przyjdź i powiedz, że nie mam racji (ale zechciej to robić w czasie swojej normalnej pracy a nie symulacji).

    • BloodMan

      Bzdury. To właśnie nazywa się pierdzielenie, wiesz? ;-) Jedyny pomysł sensowny to ten ze średnią – ale to i tak jest praktycznie /dev/random w akcji … a nóż widelec nic się nie zmieniło ;-) W ogóle to przerost formy nad treścią, nieuzasadnione użycie baz/plików/rejestru, nieuzasadnione użycie zasobów, nieuzasadnione użycie cat … Pomyśl nad tym.

    • krzysiekj

      czy zrobiłeś to o co Cię prosiłem? nie? no to pitolisz ;)

      ja sobie zrobiłem takie statystyki kiedyś

      podałem Ci przykład gdzie tak zrobili w środowisku dużo bardziej nieprzewidywalnym niż Twój blaszak na biurku – dało się? dało

      sprawdź i przyjdź z faktami

    • BloodMan

      Ja o głodzie ty o wodzie.
      To co proponujesz to przerost formy nad treścią – możesz sobie to argumentować nawet tym że w NASA tak robią, oraz że Mark Zuckenberg mówi LUBIE_TO.
      Nieważne. To jest rzecz niewarta wdrażania bo środki na to użyte są marnowaniem czasu, i programisty i procesora i wszystkich świętych. A i tak nie daje miarodajnych wyników w połowie przypadków.*
      * = połowa użyta zdupy, przeprowadź szeroko zakrojone badania i mi powiedz czy jest większa połowa czy mniejsza niż 50 ;-)

      jak wyczuwasz sarkazm to fajnie ;S

    • krzysiekj

      nie wiem kto tak robi i guzik mnie to obchodzi :)

      był postawiony problem i pytanie, dałem tylko moje odpowiedzi, Ty się po prostu nie dajesz przekonać co w zasadzie dalej nic nie znaczy i nic nie rozstrzyga :)

    • BloodMan

      Ja się nie daję przekonać i argumentuję że wszystkie znane („dobre”) sposoby są niewspółmierne do korzyści – czyli nie są dobre. Moje krótkie „nie da się” jest po prostu uproszczeniem dyskusji. I tyle.

    • krzysiekj

      BTW poczytaj o big data (tutaj mamy takie małe big data, nie istotne czy raz albo dwa aplikacja odpaliła Ci się zauważalnie wolniej lub szybciej – zwykle odpala się tak samo).
      Podobnie w życiu – o tych samych porach jesz i chodzisz do kibelka (statystycznie).

    • BloodMan

      Statystyka się załamuje. Mój styl życia jest randomowy.

    • krzysiekj

      tak Ci się tylko wydaje :)

    • BloodMan

      Nie, tak napisałem.

    • Robert Sosnowski

      I tak, i nie.

      W przypadku instalatora programu, systemu kontroli wersji, i większości innych sytuacji można by to pewnie dobrze zrobić, ale trzeba by rzucić na projekt nieprzytomnie wielkie zasoby. Tak więc to nie ma sensu, żeby praca nad paskiem progresji zabrała więcej czasu i zasobów niż cała reszta aplikacji.

      Jeden przypadek użycia opisany w artykule jest jednak sensowny. To wtedy, gdy czynność powtarzana jest wielokrotnie, np. uruchomienie gry po raz kolejny na tym samym kompie. Pewnie dałoby się to zrobić w miarę poprzez zbieranie statystyk, i ich wykorzystanie przy następnym uruchomieniu. Chociaż to też byłoby zawodne – jeśli np. inicjalizacja grafiki przeciętnie trwa dwa razy dłużej niż połączenie ze zdalnym serwerem, może się jednak okazać że danego dnia jest taki ruch sieciowy (korki na złączach), że proporcje się odwrócą.

  • Dynia

    Dla mnie mistrzostwem są skanery antywirusowe, które pokazują 5%, a później dochodzi do 98% w sekundę.

  • „Nie ma chyba nic gorszego niż zdezorientowany użytkownik oprogramowania, który irytuje się marnując czas patrząc na pasek postępu, który sugeruje, że za chwilę będzie można pracować.”

    Oj, jestem w stanie wyobrazić sobie co najmniej kilka gorszych rzeczy. Malaria, kolejność wyświetlania zdjęć na Instagramie, Gimper, Fiat Multipla…

    • Hahaha, plus za Gimpera i Instagrama

    • Bozz

      Multipla jest tak brzydka, że aż ładna, spójrz w ten sposób, może zmienisz zdanie.

  • Daniel Stawicki

    Progres nie znaczy iloci czasu ;), tak tylko zauważę. Podobnie jest z ocenianiem zapytań w SQL, widzi się jaki wynik, ale to nie znaczy że zapytanie jest najszybsze, tylko najefektowniejsze. Ale to tak pół żartem, pół serio.
    A na poważnie to zrobienie takiego paska aby pokazywal prawdziwy czas jest ogromnie skomplikowane wbrew pozorom. Do tego żeby był poprawny musiał by się chyba cofać procentowo :) Dla przykładu wstępnie oszacuje się że zapis na dysk zajmie 2 min ale cos spowoduje ze zajmie to wiecej czasu i z 2 min zrobi sie 5 min wiec poprawnie szacujac czas trzeba by przeskalowac postep procentowo w dol.

  • Bartłomiej Przybylak

    Progress bar w procentach pokazuje ile procent operacji udało się już wykonać / ile pozostało. Nie precyzuje on ile czasu zajmie mu wykonanie np: 75% zadanej operacji. Trochę mijamy się z pojęciami. Nie dziwi mnie jeśli z 5% nagle skacze do 80% i czeka 3 minuty, wykonał najpierw 5%, potem kolejne 75% operacji, a aby wykonać następne 20% czekasz bo akurat to wymaga sporego nakładu pracy. To nie stoper.

    • To zależy o jakiej operacji mówimy dla przykładu aktualizacje systemowe zawsze pokazują „przewidywany” czas – czasem sie on potem zmienia

    • Bartłomiej Przybylak

      „przewidywany” czas to nie procent, zupełnie inna bajka. Ja piszę o twoim problemie z procentami.

  • Henrar

    Musiałbyś brać pod uwagę w czasie rzeczywistym zużycie zasobów komputera (CPU, RAM, przepustowość poszczególnych pamięci i I/O) i określić z jako-takim przybliżeniem czas na zakończenie operacji. Tona zupełnie niepotrzebnego kodu, który nie dość, że spowolni cały proces ładowania/instalacji, to jeszcze jest na tyle skomplikowany, by być potencjalnym źródłem tony bugów.

  • Mailosz

    Z mojego hobbistyczno-programistycznego punktu widzenia stwierdzam, że jest to po prostu za trudne zadanie w stosunku do zysków. Stworzenie dobrego progres bara jest pewnie możliwe, ale pracochłonne, nie ma odpowiednich API, które by zwracały potrzebne wartości, trzeba szacować różne zmienne, do tego wiele działań wyrażanych przez paski postępu zależy od zmiennych warunków, np. przepustowości sieci, czy szybkości zapisu na dysku.

    Więc nie da się stwierdzić z pewnością ile % zadania się wykonało, można to tylko oszacować lepiej lub gorzej, a user i tak pewnie nie zauważy efektu.

    A nawet jak oszacujesz świetnie, to zdarzy się raz na milion, że twoje szacunki będą beznadziejne i zostaniesz zjechany na jakimś blogu za to że się nie starasz :)

    • Realnie podchodząc do tematu, „się nie da”. Jest za dużo zmiennych, które powodują wachania w kalkulacjach. Tak jak to dobrze opisałeś, przepustowość sieci jest jednym z takich elementów.

      Problem robi się dużo większy kiedy myślimy o całym systemie a nie tylko aplikacji aktualnie używanej. Sieć, tak samo jak inne podzespoły, mają określoną maksymalną przepustowość, która nie tyczy się tylko jednej aplikacji a całości. Tak więc jeżeli nasza aplikacja kopiuje/tworzy/przenosi pliki to w tym samym czasie inne aplikacje mogą tak samo zapisywać/odczytywać dane z dysku co powoduje spadek w dostępnej obecnie przepustowości. Aby stworzyć „dobry” progress bar, trzeba by było przeprowadzić kalkulacje używając bardzo zaniżonych składowych ( takich jak np. przepustowość ) i zbierać dane o procesie ( kopiowanie, pobierania … whatever ), takich jak czas i średnia ilość bajtów przemielona na sekundę. Później na podstawie tych danych można by było próbować szacunkowo określić ile dana operacja zajmie nam czasu. Oczywiście, wciąż nie było by to dokładne i najpewniej jeszcze bardziej by się myliło z szacowanym czasem…

    • Grubas

      Jak to „się nie da”? Wszystek „się da”. Się wie. Się wie, że da, lecz nie za darmo, nie tanio. Się doradzi spojrzeć szerzej.

    • zakius

      do tego całe to zbieranie danych niepotrzebnie by zużywało zasoby

    • Które mogły by dodatkowo wydłużyć dany proces przez niepotrzebny odczyt tych danych z dysku bądź pamięci operacyjnej.

      Wydaje mi się że tak jak jest teraz… jest dobrze :)

  • ✓Nose4s
    • buli

      wystarczylo przeczytac chociaz 3 pierwsze akapity zeby dowiedziec sie, ze do idealu brakuje jeszcze ile czasu pozostanie do konca. i zeby przewidzial czy w polowie kabla nie odlaczysz albo nie odpalisz torrentow.

    • ✓Nose4s

      Przewidzieć czy nie nasikasz na mobo też ma?

  • Adam K.

    Jedyny drobiazg, według mnie, to to że użytkownik nigdy nie powinien widzieć stanu 100% na pasku, bo to oznacza wykonanie zadania, więc w ułamku sekundy w którym zadanie jest wykonane w 100% pasek powinien zniknąć. Druga sprawa, to równie wątpliwe pokazanie 0%. Bo skoro pasek już zdążył się wyświetlić, znaczy zaczął realizować zadanie, filozoficznie więc patrząc, na pewno jest powyżej 0% ;)
    Szczegóły :)

    • Resquil

      Ale może to być 0,1%, a wtedy zaokrąglamy w dół ;)

  • Przemysław Rumik

    A bo problem jest w tym co ten pasek pokazuje ;-)
    Jak ktoś kodzi to tak, że mówi, że będzie N kroków i po każdym kroku zwiększa liczbę o 1 i ta liczba powoduje podniesienie progresu o 1/N*100% to będzie źle działało ;-), nawet jak doda się do tego ETA, to i ETA się będzie źle liczyło.
    Taki model będzie działał tylko wtedy jeśli krok krokowi równy ;-)

  • daverdalas

    Bądź redaktorem serwisu technologicznego i nie zdawaj sobie sprawy w czym leży problem ze stworzeniem dokładnego pasku postępu lub nie umiej tego sobie wygooglać. Brawo. Antyweb już dawno poziomem swoich artykułów sięga dna ale ostatnio to potrafi się nawet zaorać pod ziemię.

  • l.gajewski

    to jest pasek postępu, a nie czasu. Faktycznie 100% to głupota, ale nie widzę przeciwwskazań, aby przy 99% operacja +1pp zajęła 99% dotychczasowego czasu

  • techniczny

    „przecież to niemożliwe, aby nie dało się tego wyliczyć.” Albo jesteś pan ignorantem, albo idiota, albo zwyczajnie brak jakiejkolwiek wyobraźni. Cały ten artykuł to stos bredni.

    • Grubas

      Niekoniecznie. Zależy co się liczy i co mierzy. I zakładamy, że nie wychodzimy poza estymacje. Choć przyznaję, że robiłem progressbary takie, że autor tekstu mógłby napisać o nich kolejny. Ot, życie. Ale to nie znaczy, że się nie da.

  • Maruda

    Ja wiem tylko tyle, że do czasu jak był jeden pasek było OK. Ale jak się pokazały dwa paski to teraz mam córkę. I tyle w temacie pasków :)

  • Night
  • radeon hade

    Kup sobie duży ssd z 500gb i postaw na nim system + na resztę danych i paski postępu będą krótkie

    • buli

      lepiej – 256giga ramu i instalowac wszystko prosto do niego

  • Borsuk

    W wielu linuxach jest to oczywiste. Odpalasz konsolę, wklepujesz ‚sudo apt-get instal ‚ i dokładnie widzisz co się instaluje i jak szybko.

  • Paweł Grzelak

    Po pierwsze: jest to nierealne bo pasek postępu pokazuje tylko jaki procent operacji z listy operacji do wykonania, zostało już wykonane. Pasek nie ma informacji o tym, o czasie potrzebnym do wykonania tych operacji.
    Po drugie: można na podstawie poprzednich wczytywan leweli estymowac ile będzie trwało wczytywanie lewelu tym razem. I dla przykładu w Overwatch przy dołączaniu do serwera wyświetla się informacja o tym ile średnio szukanie serwera trwa na świecie w danym momencie. Jednak nie ma to wiele wspólnego z samym pisaniem skutecznych pasków postępu.

    • Grubas

      Pasek postępu pokazuje to, co zostało mu podane (z reguły jest to jedna lub trzy liczby), a nie ilość operacji.

    • Paweł Grzelak

      Tak, jasne. Ale jego postęp jest wynikiem jakiejś iteracji.

    • Grubas

      No i? Zawsze gdzieś będzie jakaś iteracja. Nadal pb możesz karmić liczbami wyznaczonymi w sposób względnie dowolny. Nie musi to być numer kroku.

    • Paweł Grzelak

      No to prawda. Chodzi mi o to, że nie przewidzisz czasu trwania każdej operacji z kolejki na tyle dokładnie, by móc wyświetlić płynny pasek postępu.

    • Paweł Grzelak

      Chodzi mi o to, że nie przewidzisz czasu potrzebnego do wykonania wszystkich operacji w kolejce, więc nie wyliczysz realnego procentowego postępu.

    • Grubas

      Są dwie rzeczy – czas trwania operacji i dokładność paska postępu. W pierwszym przypadku mówi się o *estymacji*, gdzie można posiłkować się pomiarami, statystyką i (jeśli zasadne) wiedzą historyczną. W drugim wybierasz lepiej policzalną cechę (np. sumę rozmiaru plików zamiast ich ilości).

      To że PB zwolni bądź przyspieszy nie ma znaczenia. Ważne, że widoczny jest postęp prac. A największym problemem jest dojście do 99 lub 100% i następujący po tym dłuższy zwis. To jest raczej efekt tego, że nie wszystkie operacje uwzględniono do wyświetlenia na pasku, lub ostatnie/ostatnia są/jest znacznie dłuższa od pozostałych (co też da się wyrównać wprowadzając wagi).

      Rozwiązań jest z resztą wiele. Wszystko „da się”, ale może to się po prostu nie opłacać (tj. nikt na to piniążków nie wyłoży).

    • Paweł Grzelak

      Jest dokładnie tak jak piszesz.

  • Morski Morświn

    Przeczytałem tylko początek i mogę realnie stwierdzić że autor nie wie co to jest pasek postępu i oczekuje od niego nie wiadomo czego. A ja bym chciał aby w każdym kiblu się jadło zamiast srało. [||||||||||||||…….]

  • Morski Morświn

    Dopytałem dewelopera o to i powiedział mi że robia tak specjalnie na złość. Najlepsze i działające paski trzymają tylko dla siebie!

  • Freja Draco

    Ale przecież tego praktycznie nie da się zrobić. Załóżmy, że ktoś doszlifował super-hiper pasek postępu, który potrafi ekstrapolować prędkość procesów z dokładnością poniżej 1%. Odpalasz jakąś operację dyskową i widzisz: 1 minuta, ok. Ale jeśli odpalisz w tym czasie przeglądarkę albo twój antywirus uzna, że to świetny moment, żeby coś sobie posprawdzać, albo twój system operacyjny uzna, że akurat musi coś sobie koniecznie pomielić, to już cały ten idealny szacunek bierze w łeb.

    Osobiście irytują mnie tylko pseudo paski postępu. Jakieś kręciołki, czy inne mrygające w prawo, w lewo czy w obie strony.

    Żałuję natomiast, że w większości programów występuje niechęć do wyświetlania listy oczekujących na wykonanie operacji.

  • mkp

    Gdyby paski postępu były przelewaniem wody z kubka do kubka z możliwością przewidzenia, czy i kiedy ktoś lub coś taki strumień zakłóci np. lejkiem lub zablokuje wylot, byłoby to pewnie rewolucją. Niestety takie paski, na brak możliwości przewidywania nieokreślonych problemów w podawaniu informacji, wskazują ten nieszczęsny szacowany „czas” zakończenia operacji, który jest zależny od wielu czynników tak programowych jak i sprzętowych.

  • Piotr Potulski

    Zrobienie takiego płynnie działającego paska to nie do końca banalne zadanie. Gdyby chodziło o pobieranie danych z sieci – wiadomo ile jest do pobrania, ile już się udało x/y*100% i pasek gotowy. Gorzej, gdy np. chodzi o kopiowanie plików z dysku na dysk. Dajmy na to, zaznaczyłeś jeden duży plik 100 MB i 100 000 małych po 1kB, razem wychodzi 200MB i gdyby zastosować metodę z pierwszego przykładu duży plik kopiowałby się 5% czasu a pozostałe 100 000 95%, w praktyce jeszcze trochę zajęłoby przygotowanie do tych operacji, zliczenie plików, rozmiarów. Co gorsza na każdym komputerze te proporcje byłyby różne, bo np. dysk talerzowy całkiem nieźle poradzi sobie z dużym plikiem, ale kopiowanie 100 000 małych to już dla niego mordęga, a SSD będzie w stanie robić to dużo równomierniej. Jasne, że można by zrobić lepiej, ale to kosztuje – nawet nie pieniądze, ale czas, ryzyko, a przed premierą zespół woli się skoncentrować na tym, żeby gra się nie wywalała, żeby bohater nie utykał w jakimś tam miejscu bez możliwości wyjścia, żeby nie dało się przechodzić przez obiekty itp.

  • Pawel Turowski

    A mnie irytuje, że pasków postępu nie ma jeszcze na skrzyżowaniach z sygnalizacją świetlną.

    • Grubas

      Niektóre odliczają sekundy do zielonego. Powinno to być stosowane wszędzie.

  • AceIT

    JA TEŻ!!