Kraków i okolice - szukam osób do testowania edytora OSM (Android)

Jeśli jest ktoś z Krakowa lub okolic i ma telefon z Androidem - to szukam osób do przetestowania aplikacji do edytowania.

Chcę zobaczyć jak ludzie używają StreetComplete i na podstawie tego znaleźć co warto poprawić a zostało przegapione.

Wiele rzeczy które są poważnym problemem nie są zauważane, zwłaszcza jak zrażają na samym początku.

Polegałoby to na tym że byśmy się spotkali (podjechałbym w dogodne miejsce o dogodnym czasie), pogadali jak ktoś chce i przez 15-45 minut patrzyłbym się przez ramię jak korzystasz z aplikacji StreetComplete.

Najchętniej znalazłbym osoby co wcześniej nie korzystały (bo jak one trafią na problem to najrzadziej go zgłaszają na https://github.com/streetcomplete/StreetComplete/issues ), ale i osoby co już korzystały by się przydały.

(jak znasz jakieś problemy które nie były jeszcze zgłaszane na https://github.com/streetcomplete/StreetComplete/issues to też się zgłoś/przypomnij)

Wyniki poprzedniego testu: https://github.com/streetcomplete/StreetComplete/issues/1470 (pod wpływem tego największe wykryte i poprawialne problemy zostały usunięte)

Tylko odpowiedz mi na jedno pytanie? Jaki to ma sens? Zglosilem kilka sugestii na tym forum, jak i na githubie, ale tworcy tego programu maja swoja wizje i jak ktos probuje cos sugerowac, to twierdzicie, ze ten program jest dla innej grupy docelowej, albo, ze juz cos zostalo zaimplementowane(to, ze niewygodne, to juz maly szczegol) i czlowieka splawiacie. Widzialem na githubie takze innych uzytkownikow, ktorzy tak zostali potraktowani.
Jesli zalezy wam na sugestiach uzytkownikow, to implementujcie to co uzytkownicy chca, a nie to co wy uwazacie za sluszne.

Sam program jest swietny, ale jezeli nie bedziecie sluchac uzytkownikow, to mapowicze przestana uzywac tego programu.

  1. pierwsze testy były wczoraj, niektóre błędy (buble w tłumaczeniu) już zostały poprawione. Kolejne wykryte rzeczy z tych prostszych do naprawy a powodujące poważne problemy wkrótce zostaną naprawione.

  2. implementowanie 100% zamówionych rzeczy jest niewykonalne. Samo “niech będzie wersja na iOS” to ponad pół roku pracy na pełen etat (i to zakładając że ktoś kto to robi jest ekspertem od robienia aplikacji na iOS)

Jedną z podstawowych funkcji takiego testowania jest ustalenie które problemy są powszechne i dotyczą wielu użytkowników. Umożliwia to wybranie takich rzeczy do implementacji które są tego szczególnie warte. Dodam że gdyby selekcji nie było to nowych funkcji i zmian byłoby tyle samo i tak.

A czasem takie testowanie powoduje to zmianę decyzji. Przykładowo, możliwość odpowiedzi “ten obiekt nie istnieje” była na początku odrzucona przez autora - a częściowo w wyniku poprzednich testów została dodana.

Selekcja i wybieranie istotnych rzeczy jest niezbędne - same otwarte zadania na https://github.com/streetcomplete/StreetComplete/issues to robota gdzieś na dwa-trzy lata na pełen etat dla dwóch osób. Jeśli nie więcej, A gdy zostaną przerobione to będzie 100 nowych, nawet przy ostrej selekcji.

Cała idea takich testów to zobaczyć właśnie jak program jest używany - często fundamentalne i naprawdę istotne problemy nie są zgłaszane. Bo użytkownik poległ na samym początku i nie był na tyle zaangażowany by problem zgłosić. Lub błędnie uznał że to on jest problemem a nie program.

Dodam też że jak ktoś widzi spore możliwości do poprawy - kod jest na otwartej licencji, można zrobić swoją wersję (tak, nie jest to trywialne i ilość osób które nauczyły się programować jest ograniczona - dlatego ostra selekcja zadań do zrobienia jest niezbędna).

Tak, część rzeczy jest odrzucana bo ta aplikacja ma określony cel/zastosowanie - ma być używalna przez ludzi z zerowym doświadczeniem.

https://en.wikipedia.org/wiki/Feature_creep https://en.wikipedia.org/wiki/Design_by_committee https://blog.codinghorror.com/this-is-what-happens-when-you-let-developers-create-ui/ to niektóre ze znanych problemów (przepraszam za linki po angielsku - ale jak zwykle z programowaniem wszystko jest po angielsku)

Super, ze zostaly jakies bledy wykryte. Teraz trzeba to naprawic i bedzie git. A tak z ciekawosci, jakiego rodzaju bledy zostaly wykryte, nie liczac baboli jezykowych?

To juz jest skrajny przypadek i ciezko to zaliczyc do feature-a. Wersja na iOSa, to osobny projekt, ktory by musial byc zarzadzany przez osobe, ktora uzywa iOSa, a nie osobe, ktora iOSa nie uzywa.
Mozna by to zakwalifikowac jako feature, tylko wtedy, gdy program bylby tworzony przy uzyciu wieloplatformowej biblioteki, typu Qt, choc nie wiem, czy maja wersje na iOSa.

To moze zrobcie jakas ankiete z lista funkcji, ktore by chcieli dodac uzytkownicy i niech glosuja i wtedy bedzie wiadomo, jakie funkcjonalnosci sa potrzebne, a jakie nie. Da sie takie cos zrobic na tym forum? wtedy glosowalyby osoby, ktore rzeczywiscie uzywaja OSM.

Skoro tak twierdzisz, to ankieta bylaby idealna, zeby sie dowiedziec, jakie funkcje sa potrzebne.

Ciezko liczyc, zeby osoby nietechniczne (rozumiem, ze dla tego typu osob, ten program jest tworzony) tworzyly konto na githubie, portalu typowo dla programistow.

To akurat bardzo nietrafiony powod, a wrecz szkodliwy dla rozwoju programu.
Podobne poglady sa wsrod tworcow dystrybucji Linuksa i przez to jest 50tys dystrybucji, z czego tak naprawde tylko kilka, czy kilkanascie wnosza cos sensownego do linuksa. Takie poglady, zamiast tworzyc spolecznosc wokol programu, to ja rozdrabnia i powoduje, ze programy sie wolniej rozwijaja. W programach opensource, jakby sie ludzie probowali dogadac, to byloby znacznie wiecej wartosciowych programow.

A czy to przeszkadza w dodawaniu bardziej zaawansowanych funkcji? Jest wiele programow, ktore na dzien dobry ma prosty interfejs, a w opcjach mozna wlaczyc baardziej zaawansowane funkcje. To w niczym nie przeszkadza, zeby jednego programu uzywali ludzie mniej obeznani z tematem, jak i bardziej obeznani.

Jeżeli ktoś chce mieć narzędzia do zaawansowanej edycji na Androidzie, to jest już dostępny Vespucci, a to jaki UX ma, jest niestety po części wynikiem dodania tych wszystkich funkcji. Nie da się z kalkulatora zrobić edytora arkuszy kalkulacyjnych i liczyć na to, że nadal będzie tak samo prosty w obsłudze, czas autora też nie jest z gumy. Osobiście popieram obraną ścieżkę tworzenia programu o jasno określonej wizji.

Zasadniczo nie, była nawet próba dodania bardziej zaawansowanych opcji edytowania ale zabrakło na to czasu w ramach tego co był dostępny. Por. https://github.com/streetcomplete/StreetComplete/issues/2461 Tobias Zwick (główny autor aplikacji) miał więcej czasu niż zwykle, w tym na duże projekty dzięki grantowi 01IS20S35 z niemieckiego ministerstwa edukacji i nauki ( https://github.com/streetcomplete/StreetComplete#sponsors ) ale na tą część czasu zabrakło. I tak przez kilka miesięcy nie brał płatnej pracy bo kończył przebudowę wewnętrznej struktury danych.

Zastanawiam się czy jednym z moich następnych projektów nie będzie czasem kontynuacja tego ale to konkuruje z innymi rzeczami które czekają na implementacje. W tym momencie w potencjalnych planach mam rozpisane projekty na około 5000h pracy (ponad dwa lata pracy na pełen etat).

Przy okazji jak na to zeszło: jak ktoś miałby ochotę pomóc/porobić coś z Androidem/Kotline na rzeczywistym projekcie to https://github.com/streetcomplete/StreetComplete/issues/3127 https://github.com/streetcomplete/StreetComplete/issues/3130 https://github.com/streetcomplete/StreetComplete/issues/3142 są dość sympatyczne do implementacji (pytania tak/nie)

Ja ktoś ma ochotę spróbować a utknął niech da znać to pomogę.

Uzywanie Vespucci na telefonie, to jest jakies nieporozumienie, zwlaszcza jak ma sie duze dlonie. Uzywanie Vespucci ma sens tylko jak ma sie jakis rysik, albo na tablecie. Wtedy to ma jakis sens. Ciezko palcem dokladnie wskazac punkt na ekranie, wiec uzywanie Vespucci do czegos powazniejszego, to wg mnie jakies nieporozumienie.
Mi nie chodzi o robienie klona Vespucci, tylko o kilka funkcji, ktore by umozliwily szybsze uzupelnianie OSM.

Przykladowo, ja najchetniej bym zobaczyl mozliwosc podejrzenia tagow do edytowanego obiektu. NAwet nie chodzi o edycje, ale o sam podglad, ktory by umozliwil zaznajomienie sie z nowymi tagami i opcjami.

Takie cos, wydaje mi sie ze byloby bardzo przydatne dla nowych uzytkownikow, gdyz umozliwiloby im na zaznajomienie sie z dostepnymi tagami na osm, a w koncu dla nowych uzytkownikow ten program jest glownie kierowany. Wydaje mi sie, ze zaimplementowanie takiej funkcji nie zabraloby zbyt wiele czasu, bo obecnie i tak program musi czytac wszystkie opcje, zeby wiedziec jakie pytania wyswietlic.

Druga funkcja (dla zaawansowanych), ktora by sie przydala, to mozliwosc recznej edycji tagow. Nie chodzi mi o edytowanie jakis skomplikowanych relacji itp, ale o proste obiekty, typu lawki, budynki (co do tego, to nie jestem pewien, bo mozna dodawac tagi do 3D), kosze, sklepy itp. Te obiekty sa niezalezne od siebie, wiec nawet jak sie wpisze cos zle, to nie bedzie tragedii. Sposobem na ograniczenie blednych edycji, bylaby mozliwosc podpowiedzi, tak jak to robi JOSM. Liste tagow i mozliwych opcji moglby przygotowac kazdy, nawet nie majacy doswiadczenia programistycznego. Ta funkcja umozliwilaby dodawanie tagow, zanim sie pojawi odpowiednie pytanie w SC.

Ostatnia funkcja, ktorej mi bardzo brakuje, to dodanie do pierwszego okna wszystkich pytan, dodatkowego przycisku “Pomiń”. Podobna propozycje ktos inny zaproponowal, tyle, ze w formie listy wszystkich pytan dla danego obiektu i mozliwosc przeskakiwania miedzy nimi.
Podam przykład.
Jest jakiś obiekt (powiedzmy budynek) i np 5 pytań dla tego budynku. Na pytanie 1, 2 i 5 mogę odpowiedzieć będąc z przodu budynku, ale na pytania 3 i 4 muszę się przenieść na drugą stronę budynku.
Obecnie, mozna zrobic tak, ze odpowie sie na pytanie 1 i 2, a pytania 3 i 4 trzeba ukryc, lub dodac uwage, chcac przejsc do pytania nr 5, co nie jest idealnym rozwiazaniem, bo takie pytania juz sie nie pojawiaja, wiec obiekt ma mniej uzupelnionych tagow, niz moglby miec.
Innym sposobem jest odpowiedz na pytanie 1 i 2, przejscie na druga strone budynku, odpowiedzenie na pytania 3 i 4, a nastepnie znowu powrot na przod budynku, zeby odpowiedziec na pytanie 5. Ja, w wiekszosci przypadkow, juz nie wracam do pytania nr 5, bo mi sie po prostu nie chce specjalnie wracac na przod budynku.

Chetnie bym uslyszal opinie MAteusza do tych propozycji i ile czasu mogloby zajac zaimplementowanie takich funkcji.

Odnośnie UX w StreetComplete mam dwie uwagi:

  1. Jak jestem na spacerze i uzupełniam dane na temat danego budynku to akurat na niego patrzę i chcę uzupełniać danę tego budynku, jednak StreetComplete czasem robi z tego budynku kropkę, której nie da się kliknąć, a można jedynie kliknąć w budynek obok, co zmusza albo do zmiany widoku, albo do ciągłego przerzucania się między uzupełnianiem danych dla dwu budynków obok siebie. Dobrze by było jakby ostatnio edytowany budynek się nie kropkował, a najlepiej by było jakby od razu po podaniu jednej danej, uruchamiało się następne pytanie dotyczące tego samego budynku.
  2. Odnośnie zostawiania komentarzy ze zdjęciem, to nie ma opcji na ani cofnięcie komentarza, ani na dodanie dodatkowego komentarza. Niekiedy jest tak, że nie widzę w danym miejscu wejścia ścieżki leśnej, a jest paręnaście metrów dalej, więc najpierw zostawiam komentarz, że nie ma tu żadnej ścieżki, a następnie nie mogę już nic z nim zrobić gdy odkryję że ścieżka jest, jednak w złym miejscu.

ad1) Dzięki! Widze że jeszcze jeden głos w tym temacie. Na pewno coś będę usiłował tu coś poprawić.

as2) W sensie po wysłaniu komentarza do uwagi lub uwagi?

ad2) Chodzi dokładnie o funkcję “Utwórz nowe zgłoszenie o problemie”, wywoływane przez długie wciśnięcie miejsca na mapie.