watchOs 7 - nie zmienia nic

Marketing Apple zawsze stosuje górnolotne określenia w stylu „Redefiniowane”, „Odkryte na nowo”, czy „Zmienia wszystko”. Po zapoznaniu się z pierwszymi wersjami beta nowego systemu dla zegarka Apple Watch – watchOS 7 – uprzejmie podpowiadamy stosowne hasło: „Nie zmienia absolutnie nic”. Jeśli jesteście posiadaczami aplikacji na Apple Watch i owa aplikacja pracuje poprawnie na watchOS 6, nową wersję systemu watchOS 7 – przynajmniej na etapie obecnej wersji beta – możecie spokojnie zignorować. Oczywiście zmiany w samym systemie są – nowe tarcze zegarka, nowa aplikacja do śledzenia snu, nowe drobne funkcje zorientowane na użytkownika itd. jednak w kwestiach, pod którymi my rozpatrujemy nowe wersje oprogramowania systemowego – ewentualnych wymaganych korekt w aplikacjach i potrzeby ich aktualizacji – jakichkolwiek zmian nie widać. Ten update systemu watchOS jest przeznaczony przede wszystkim dla użytkowników końcowych, dla deweloperów wnosi niewiele, a dla właścicieli aplikacji nic.

Należy jednak pamiętać, że Apple na koniec roku zapowiedziało zmiany w App Store dotyczące prywatności użytkowników i wykorzystywania danych przez aplikacje. Najprawdopodobniej w związku z tym nie będą wymagane zmiany w kodzie aplikacji – całość będzie polegała na konieczności wypełniania dodatkowego formularza w samym sklepie dotyczącego prywatności i wykorzystania danych. Zmiana jest zapowiadana na grudzień tego roku, zatem warto śledzić kolejne informacje ogłaszane przez Apple.

 

iOS 14, czyli widżety na nowo

Jesienią, jak co roku będzie dostępna nowa wersja systemu iOS dla iPhone i iPadów. Tym razem w wersji 14. Pojawiły się już pierwsze deweloperskie wersje beta zatem sprawdzamy co nowego. Jak zawsze w naszych wczesnych testach skoncentrujemy się na ewentualnych zmianach wymagających aktualizacji aplikacji opublikowanych w App Store, abyście wiedzieli, czy trzeba przygotować się na ewentualne zmiany, czy też śmiało możecie odłożyć update o rok.
Celem wyjaśnienia – wiemy, że system iOS instalowany na iPadach formalnie nazywa się iPadOS, jednak jakkolwiek dział marketingu Apple stawałby na głowie usiłując przekonać wszystkich, że jest to odrębny system operacyjny, to w rzeczywistości wcale tak nie jest. iPadOS to po prostu iOS z drobnymi zmianami interfejsu dla większych ekranów.

Na pierwszy rzut oka – po przejściu na springboard (pulpit) urządzenia – iOS 14 nie różni się niczym od iOS 13. Wystarczy jednak wykonać gest przeciągnięcia ekranu w lewo lub prawo, aby zobaczyć, że zmiany wprowadzono. Nie są
to jednak zmiany rewolucyjne, które spowodują, że aplikacje działające na iOS 13 będą wymagały aktualizacji. Nie zauważyliśmy niekompatybilności na poziomie kodu, tak więc jeśli nie planujecie udostępniać waszym użytkownikom nowych funkcjonalności wprowadzanych wraz z iOS 14, nie musicie planować aktualizacji. Nowości o których wspominamy, to nowe funkcje widoczne właśnie po wykonaniu gestu przeciągnięcia ekranu ze springboadru w prawo lub lewo – nowe widżety i tzw. App Gallery.

App Gallery nie wymaga żadnej ingerencji w kod aplikacji i jest w pełni obsługiwane na poziomie systemu operacyjnego. Użytkownik może nie odinstalowywać aplikacji, a przenieść ją do dedykowanych katalogów pogrupowanych tematycznie dostępnych po wykonaniu gestu przeciągnięcia w lewo ze springboardu – ikona aplikacji jest wówczas usuwana z pulpitu i umieszczana w App Gallery w katalogu pasującym do kategorii danego programu typu „narzędzia”, „Gry” itp. Tą nowość można śmiało określić jako zmianę kosmetyczną.

Ciekawsze rzeczy dzieją się po wykonaniu gestu przeciągnięcia w prawo ze springboardu lub przytrzymaniu punktowo palca na pulpicie – nowe widżety. iOS 14 wprowadza nowe widżety na wzór tych znanych z Androida. Można je dowolnie umieszczać w galerii widżetów, ale także – co w iOS jest nowością – rozmieszczać pomiędzy ikonami na pulpicie. Warto zwrócić uwagę, że widżety starszego typu z iOS 13 nie są kompatybilne z nowymi. Jeśli wasza aplikacja jest wyposażona w widżet starszego typu, nie będzie on działał jak nowe widżety. Starsze widżety nadal działają, jednak można je umieszczać tylko w wybranym miejscu – w galerii widżetów i zawsze na samym dole listy w odrębnej sekcji pod nowymi widżetami. Jeśli zatem chcecie zaoferować swoim użytkownikom nowy widżet iOS 14 niezbędna będzie aktualizacja aplikacji. Nowe widżety mają trzy rozmiary – mały, średni i duży – i przynajmniej w wersji beta dość znacząco ograniczoną funkcjonalność w porównaniu do widżetów starszego typu. Na przykład nie można z ich poziomu wykonywać określonej akcji w samej aplikacji – służą raczej jako duża ikona, która może być aktualizowana z kodu aplikacji.

Przyglądając się nowemu iOS warto także zwrócić uwagę na zmiany zapowiedziane przez Apple w samym App Store na koniec roku. Podobnie jak w Google Play mają być to zmiany dotyczące prywatności użytkowników i wykorzystywania danych przez aplikacje. W przeciwieństwie do Google najprawdopodobniej nie będą wymagane zmiany w samym kodzie aplikacji, jednak w App Store ma pojawić się nowa sekcja dotycząca prywatności – rozbudowany formularz dotyczący ochrony prywatności i wykorzystania danych, który każdy właściciel aplikacji będzie musiał wypełnić chcąc opublikować aktualizację programu lub wydać nową aplikację.

 

Android 11 beta - co nowego

Nowy rok, nowy Android – tym razem o numerze 11 i oznaczeniu kodowym R. Jak zawsze przyglądamy się wersji beta, aby sprawdzić na co należy być przygotowanym i czy w ogóle trzeba coś robić, jeśli ma się aplikacje na Androida opublikowane na platformie Google Play. Ostateczna publiczna wersja systemu będzie dostępna jesienią i wówczas ewentualne zmiany zostaną wprowadzone w konsoli Google Play. Posiadacze aplikacji opublikowanych w HUAWEI AppGallery nie muszą się specjalnie zastanawiać, gdyż ta platforma jest oparta o AOSP (Android Open Source Project) i jako taka nie podlega zmianom i wymaganiom wprowadzanym przez Google w usługach i serwisach tej firmy.

Największe zmiany w systemie w wersji 11 dotyczą opcji prywatności i uzyskiwania uprawnień od użytkownika. Lista tzw. uprawnień wrażliwych, na której dotychczas były telefon, SMS i czujniki związane z kondycją fizyczną i zdrowiem użytkownika, została rozszerzona o uprawnienia do lokalizacji w tle. To oznacza, że na lokalizację w tle trzeba uzyskać dodatkowe pozwolenie od użytkownika. Użytkownicy mogą teraz taże w dowolnej chwili przyznać lub cofnąć konkretne uprawnienie dla poszczególnych aplikacji. Jeśli zatem wasza aplikacja korzysta z lokalizacji w tle lub kilku odrębnych uprawnień, warto pamiętać aby przygotować ją na możliwość wycofania dowolnego uprawnienia w każdej chwili (dodać obsługę zmiany uprawnienia w każdym momencie, jeśli w kodzie aplikacji nie jest to obsługiwane – co wciąż się zdarza zwłaszcza w kodzie, który został przygotowany dla wcześniejszych wersji Androida i nie był od dłuższego czasu aktualizowany).
Pozostałe zmiany należą do kategorii kosmetycznych i optymalizacyjnych – drobne korekty w wyglądzie (niewielkie), uporządkowanie belki systemowej, porządki w szufladce ustawień, estetyczne poprawki w powiadomieniach itp.

Mając aplikację na Androida zawsze trzeba zwracać uwagę na tzw. target, czyli wersję API, na którym aplikacja jest oparta. Obecnie aby opublikować aplikację lub wydać aktualizację w Google Play wymagany jest target 29, czyli aplikacja musi być dostosowana do Androida 10. Nowa wersja Androida ma target 30, jednak nie zmienia wymagań targetu minimalnego – nadal jest to 29. Nie dostrzegliśmy także innych niekompatybilności, zatem jeśli wasza aplikacja jest targetowana numerem 29 to raczej nie musicie się niczym martwić, a jeśli macie aplikację targetowaną niższym API i tak musicie ją dostosować do targetu 29 jeśli chcecie opublikować aktualizację. Biorąc jednak pod uwagę kolejne zmiany wprowadzane w opcjach prywatności systemu w wersji 11 spodziewamy się, że z czasem pojawią się nowe wymagania. Trudno na etapie dość wczesnej jeszcze wersji beta systemu stwierdzić, czy będą wymagane zmiany w samych aplikacjach, tak jak miało to miejsce przed rokiem przy okazji przejścia na Androida 10, czy też może raczej zmiany będą dotyczyły tylko konsoli Google Play, niemniej jednak jeśli jesteście właścicielami konta w Google Play warto zachowywać czujność w tej kwestii i śledzić kolejne informacje publikowane przez Google.

 

Wsparcie z FOSA

„Wsparcie w Gdańsku!” to pierwsza tego typu aplikacja w Polsce – nie tylko z nazwy, ale i realnie funkcjonująca na rzecz wsparcia osób z zaburzeniami psychicznymi. Realnie, gdyż po drugiej stronie ekranu smartfonów z Androidem, na których działa ten program, stoją realni ludzie – specjaliści z fundacji FOSA, od wielu lat zajmujący się pracą z osobami doświadczającymi kryzysów i trudności natury psychicznej. Skrót FOSA rozwija się jako Fundacja Oparcia Społecznego Aleksandry, a możliwość uczestniczenia w projekcie finansowanym przez Miasto Gdańsk, mającym na celu zapewnić realną pomoc mieszkańcom miasta borykającym się z problemami natury psychicznej, była dla nas i prawdziwą radością i jednocześnie ciekawą przygodą.

Samo projektowanie aplikacji od strony czysto programistycznej niczym nie różniło się oczywiście od programowania innych aplikacji – lubimy swoją pracę więc zawsze wykonujemy ją z pełnym zaangażowaniem – jednak od strony merytorycznej to już zupełnie inna historia. Fascynujące było obserwowanie jak bardzo zwykły program na Androida, w rękach doświadczonych psychologów, z narzędzia po prostu pomocnego i praktycznego – realizującego swoje funkcje – potrafi zmienić się w narzędzie przyjazne – narzędzie komunikujące się z użytkownikiem językiem dostosowanym do potrzeb grupy użytkowników, do której jest kierowane. Dotychczas z profesjonalnej pomocy w układaniu komunikatów, czy projektowaniu komunikacji wizualnej korzystaliśmy głównie podczas projektowania aplikacji dla dzieci, co wydaje się oczywiste. Tym razem mieliśmy okazję przyjrzeć się podobnej pracy wykonywanej podczas projektowania aplikacji przeznaczonej głównie dla dorosłego odbiorcy. Zaskakujące jak bardzo standardowe alerty, czy komunikaty, do których wszyscy jesteśmy przyzwyczajeni w oprogramowaniu wszelkiego typu, mogą różnić się, gdy są ściśle kierowane do określonej grupy ludzi. Wychodzi na to, że słowa mają znaczenie.

 

 

Jaką technologię na siebie włożyć?

Styczeń sprzyja wszelkiego rodzaju podsumowaniom i zestawieniom. My postanowiliśmy przyjrzeć się rynkowi elektronicznych urządzeń, które można na siebie założyć, czyli tzw. wearables. Skłoniły nas do tego publikowane w 2019 roku niezależne raporty Canalys i IDG, analizujące ten rynek. Raporty obu firm analitycznych różnią się podawanymi liczbami, jednak jedno je łączy – na pierwszy rzut oka mają wydźwięk entuzjastyczny – rynek urządzeń wearables, po lekkiej zadyszce w roku 2018, w roku 2019 rósł jak na drożdżach o blisko 100% rok do roku. Diabeł tkwi jednak w szczegółach – do kategorii produktów wearables zaliczają się nie tylko zegarki, opaski fitness itp. ale także słuchawki – to głównie ich sprzedaż wygenerowała tak znaczący wzrost. Kategorie produktów takich, jak zegarki, czy opaski fitness też rosną – uśredniając o ok. 40% w stosunku rok do roku – jednak znacznie mniej dynamicznie. Przyjmując uśrednione wartości z zestawień obu domów analitycznych, na światowym rynku sprzedano blisko 180 milionów urządzeń typu wearables. Z czego 48% to słuchawki, 23% opaski fitness, 21% zegarki. 8% stanowiły produkty z kategorii „inne”. Światowym liderem sprzedaży wearables jest Apple – 35%, na drugim miejscu Xiaomi – 14,6%, trzecią lokatę zajmuje Samsung – 9,8%, czwartą Huawei – 8,4%, piątą Fibit – 4,1%, a inni producenci stanowią pozostałe 28,1%.
Na rynku polskim sytuacja jest zupełnie inna – najwięcej do powiedzenia mają firmy oferujące produkty zdecydowanie tańsze od Apple i Samsunga. Liderem polskiego rynku wearables jest Huawei – 32%, goni go Xiaomi – 26%, trzeci stopień podium należy do Samsunga – 22%, a Apple znalazło się na miejscu czwartym – 14%. Pozostałe 6% to producenci „inni”.

Statystyki i analizy swoją drogą, lecz nas z całej tej kategorii produktów interesują najbardziej dwa: zegarki i opaski fitness, jako że są to urządzenia pozwalające na opracowywanie użytecznych aplikacji. Biorąc pod uwagę strukturę sprzedaży widać wyraźnie, że rynek urządzeń tego typu dojrzał. Notuje niezbyt spektakularny, jednak stabilny wzrost, co oznacza, że tam, gdzie jest to zasadne, aplikacja pracująca na nadgarstku użytkownika powinna być ujmowana w planie produkcji oprogramowania, jako wartościowe uzupełnienie „workflow” lub możliwy kanał dotarcia. Na pewno w procesie projektowania środowiska programowego nie warto brać pod uwagę aplikacji na urządzenia ubieralne z tzw. powodów prestiżowych, czy w celach czysto marketingowych – biorąc pod uwagę strukturę rynku, zlecanie produkcji aplikacji na zegarki w takim wypadku byłoby wyłącznie sztuką dla sztuki. Reszta scenariuszy zależy od analizy przypadku. W sytuacjach, gdy ma to uzasadnienie z użytkowego punktu widzenia, wearables powinny być włączane w projekt.

Należy jednak wziąć pod uwagę, że samo planowanie w najbliższym czasie będzie trudne z powodu obarczenia procesu jedną dużą niewiadomą. Rynek wearables, w który ewentualnie warto inwestować, od strony programowej obejmuje trzy główne systemy operacyjne – watchOS (Apple), Tizen (Samsung) i WearOS (Google). O ile pozycja pierwszych dwóch jest stabilna z tendencją wyraźnie wzrostową (razem pokrywają blisko 50% rynku), o tyle sytuacja z WearOS jest zastanawiająca. Google najwyraźniej ma poważny problem z wypromowaniem swojego systemu – obecnie korzystają z niego po części Huawei i Xiaomi, rzadko Samsung, a jednym z największych producentów wykorzystujących system Google jest Fossil – nie ujęty nawet w raportach Canalys i IDG. Sytuacja WearOS jest zatem niepewna. Czy niedawne przejęcie firmy Fibit przez Google coś tutaj zmieni? Czas pokaże.

Oprogramowanie dedykowane

Ostatnio pytaliście nas o co chodzi, gdy używany jest termin „Oprogramowanie dedykowane”. Wiele osób uważa, że jest to po prostu aplikacja przeznaczona dla konkretnego systemu operacyjnego, niedostępna na konkurencyjnej platformie. Czyli np. aplikacja jest dedykowana Androidowi, gdyż jest niedostępna dla systemu iOS. Nie jest to właściwa definicja tego pojęcia – o ile o jakiejkolwiek definicji można tu mówić. W żargonie informatyków, czy programistów „Oprogramowanie dedykowane” to po prostu program pisany na indywidualne zamówienie np. przedsiębiorstwa, czy instytucji i ściśle dostosowany do ich potrzeb. Są to programy niedostępne do użytku ogólnego, nie można ich pobrać z internetu, czy kupić. Oprogramowanie takie jest instalowane tylko i wyłącznie w infrastrukturze zamawiającego i służy poprawie pracy jego organizacji, czy też ma za zadanie doprowadzić do konkretnych celów – np. przynieść oszczędności poprzez usprawnienie wybranych procesów.

Czy zatem każde przedsiębiorstwo, instytucja powinna zamawiać indywidualne oprogramowanie pisane tylko dla siebie? Nie zawsze jest to zasadne. Często wystarczy użycie oprogramowania ogólnodostępnego. Jednak w dobrze przemyślanych przypadkach oprogramowanie dedykowane potrafi zapewnić wymierne i policzalne oszczędności inwestorowi i wówczas warto rozważyć jego zlecenie – czysta matematyka i twardy rachunek ekonomiczny mają tutaj głos rozstrzygający.

Przykładowo jeśli oprogramowanie może przyspieszyć proces obsługi klienta, a co za tym idzie zwiększyć liczbę osób obsługiwanych dziennie zwiększając tym samym zyski przedsiębiorstwa, jego wdrożenie będzie zasadne. Taki schemat znalazł zastosowanie m.in. w Punkcie Selektywnej Zbiórki Odpadów w Piasecznie. Dedykowany system dla tego przedsiębiorstwa usprawnia i przyspiesza proces obsługi klienta, a także wspomaga rozliczenia, prowadzenie statystyk i sporządzanie raportów. Oprogramowanie składa się z dwóch modułów:
– aplikacji dla tabletów z Androidem stosowanej w punktach obsługi klienta, bezpośrednio połączonej z systemem lokalnej karty miejskiej, co pozwala na znaczące przyspieszenie procesu przyjmowania odpadów poprzez automatyczną identyfikację klienta i pobranie jego danych niezbędnych do poprawnego rozliczenia,
– dedykowanego systemu on-line zbierającego dane z modułów terenowych, sporządzającego statystyki, rozliczenia, wizualizującego dane w postaci czytelnych wykresów, map i zestawień.

Inny scenariusz zakłada oszczędności wynikające z możliwości wykorzystania dzięki oprogramowaniu dedykowanemu istniejących zasobów, na których użycie nie pozwala oprogramowanie ogólnego użytku. Tutaj przykładem może być system przedszkolny Miasta i Gminy Piaseczno w pełni połączony i wykorzystujący zasoby istniejącego w samorządzie systemu Karty Miejskiej, co pozwoliło na znaczne oszczędności – miasto nie musi wydawać rodzicom dzieci dodatkowych kart przedszkolnych, których produkcja jest kosztowna. Do zgłaszania i rozliczania obecności dziecka w przedszkolu używana jest wydawana wszystkim mieszkańcom Karta Miejska. Sam system składa się z centralnego modułu ewidencyjnego oraz modułów zewnętrznych w postaci oprogramowania czytników NFC umieszczonych w przedszkolach. Umożliwia w pełni automatyczne ewidencjonowanie czasu przebywania dzieci w placówkach i dokonywanie rozliczeń, sporządzanie statystyk, raportów itp.

Internet rzeczy

Wyobraźcie sobie taką scenkę: wracacie autobusem z pracy do domu, tuż po wejściu do pojazdu wasz smartfon wibruje – powiadomienie o pobraniu opłaty za bilet – kasowników w autobusach nie ma od dawna. Chwilę później kolejne powiadomienie – lodówka uprzejmie informuje że skończyło się mleko, wobec czego zamówiła nową butelkę i po powrocie należy odebrać przesyłkę dostarczoną dronem na balkon, a ponadto kończy się termin przydatności do spożycia sera, w związku z czym trzeba go dziś zjeść lub wyrzucić. Czytacie dobre rady własnej lodówki i przy okazji wydajecie dyspozycję, że po waszym powrocie w domu ma panować temperatura 20 stopni, w ekspresie ma być gorąca kawa, a z głośników mają dobiegać dźwięki V symfonii Beethovena. Poinstruowany dom ustawi wymagane przez was parametry nie za wcześnie, żeby oszczędzać energię. Dom „wie” gdzie jesteście i kiedy wrócicie – zna wsze położenie dzięki geolokalizacji.

Wizja przyszłości? Otóż nie. Technologie pozwalające na taki styl życia są dostępne obecnie. Nie są jeszcze powszechne (poza geolokalizacją – choć na razie zamiast waszego domu o tym gdzie jesteście najlepiej wie Google), jednak za kilka-kilkanaście lat tak będzie wyglądało codzienne funkcjonowanie. Umożliwi to Internet rzeczy (z angielskiego IoT – Internet of Things). Wbrew pozorom nie jest to nowa koncepcja. Pierwszy raz użyto tej nazwy w 1999 r. Wówczas jednak brzmiało to jak futurystyczne mrzonki. Dwadzieścia lat później nikt już nie reaguje ironią, gdy pada ta nazwa. Smartfony, smartzegarki, smartopaski, smart-TV, smart-pralki, smart-lodówki – wszystko staje się „smart”, czyli wyposażone w oprogramowanie, aplikacje i połączone z Internetem. Każdy przedmiot codziennego użytku wkrótce będzie miał stałe połączenie z internetem. Nie tylko wszystkie moduły wchodzące w skład inteligentnych domów – sprzęt RTV, AGD, oświetlenie, instalacja grzewcza, liczniki, zegary. Także samochody, czujniki, czytniki stosowane w przemyśle, transporcie, czy handlu – wszystko połączone z siecią i wzajemnie wymieniające informacje – Internet rzeczy.

Rozwój i budowa IoT właśnie trwa – planując swoje działania na rynku oprogramowania, czy potrzeby IT dla swojej firmy lub organizacji należy mieć go na uwadze. Od mglistej idei do rozpoczęcia faktycznej budowy IoT minęło 20 lat. Za kolejne 20 lat Internet rzeczy będzie częścią codzienności. Rodzi to oczywiście dylematy natury odmiennej jak rozważania czysto programistyczne, czy technologiczne – np. kwestie prywatności, możliwości permanentnej inwigilacji (już obecnie każdy, kto ma smartfon z Androidem powinien coś na ten temat wiedzieć) – my jednak na naszym blogu zajmujemy się sprawami wyłącznie technologicznymi i związanymi z programowaniem, zatem roztrząsanie kwestii etycznych zostawimy autorom blogów o etyce.

WCAG 2.1 zamiast WCAG 2.0

Nareszcie – tym krótkim słowem moglibyśmy podsumować wejście w życie „Ustawy o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych” z 4 kwietnia 2019 r. Ustawa ta zmienia archaiczne założenia „Rozporządzenia Rady Ministrów z 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności”, wymagającego dostosowania stron www do nieaktualnego od czerwca 2018 roku standardu WCAG 2.0 i wprowadza współczesny standard WCAG 2.1 – ARIA. Co to oznacza dla idei dostępności stron www dla osób niepełnosprawnych i sprawdzania tejże dostępności w postaci audytu strony www?

Zasadniczo niewiele, jednak w szczegółach bardzo dużo. Ramy samego audytu nie ulegają zmianie – nadal sprawdzana jest dostępność stron www do poziomu AA specyfikacji WCAG i nadal wymagane jest aby odbywało się to przy aktywnym współudziale osób niepełnosprawnych. Jednak specyfikacja WCAG 2.1 dostosowuje jednocześnie swoje wymagania do wymagań współczesnego rynku informatycznego, dzięki czemu nie narzuca już twórcom stron www i systemów teleinformatycznych przestarzałych rozwiązań. Sama ustawa porządkuje też kwestie certyfikacji dostosowania i deklaracji dostępności strony www, które to kwestie były całkowicie nieuregulowane w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. Mianowicie podmiot prowadzący audyt WCAG 2.1, zgodnie z wytycznymi specyfikacji WAI-ARIA, na koniec badania wystawia badanemu systemowi deklarację zgodności na usystematyzowanym formularzu stanowiącym załącznik do Ustawy – brak tego dokumentu był niezwykle odczuwalny w RRM z 12 kwietnia 2012 roku.

Nowa ustawa zasadniczo poprawia też sytuację deweloperów budujących strony www, którzy chcą (lub muszą, jeśli są to strony przeznaczone dla podmiotów administracji publicznej) dostosować swoje produkty do potrzeb osób niepełnosprawnych. Kierując się bowiem Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności należało m.in. zrezygnować z pełnego wykorzystania Java Scriptu. Strony niedziałające z wyłączonym Java Scriptem, według wytycznych WCAG 2.0 całkowicie bowiem nie spełniają zasady 4 – Kompatybilność. Aby zrozumieć dlaczego tak jest należy uzmysłowić sobie, że założenie dotyczące Java Scriptu przyjęte w wersji 2.0 specyfikacji WCAG pochodzi sprzed blisko dekady. W międzyczasie, w systemach informatycznych oraz samej specyfikacji WCAG dokonał się znaczący postęp. Sama specyfikacja WCAG, w czerwcu 2018 r., została opublikowana w wersji 2.1 uznającej i dostosowującej wytyczne do zmieniających się technologii informatycznych oraz nieustannie rozwijanych technologii asystujących wykorzystywanych przez osoby niepełnosprawne. WCAG 2.1 zmienia m.in. zasadę 4 – Kompatybilność. Zniesiony w niej został m.in. wymóg poprawnej obsługi systemu informatycznego z wyłączonym Java Scriptem, jako że od co najmniej 5 lat na rynku nie ma urządzenia bądź technologii asystującej nie obsługującej poprawnie Java Scriptu, który sam w sobie został włączony do podstawowej semantyki języka HTML, który to z kolei w ciągu ostatnich lat standaryzowano w wersji 5 (specyfikacja WCAG 2.0 odnosi się jeszcze do semantyki HTML 4).

WCAG 2.1 jest częścią WAI ARIA – (Web Accessibility Initiative – Accessible Rich Internet Applications) – specyfikacji technicznej opublikowanej przez W3C, zawierającej zestaw rekomendacji dotyczących poprawy dostępności złożonych aplikacji internetowych. WCAG 2.0, do którego odnosi się RRM z dnia 12 kwietnia 2012 r., nie uwzględnia standardu ARIA, jako, że w momencie publikacji tej wersji WCAG nie był on jeszcze dostępny (został wprowadzony 5 lat później), a kolejna wersja – WCAG 2.1 – stała się formalnie częścią ARIA – stanowiąc jej drugi rozdział.

W związku z wprowadzeniem ARIA dalsze odrębne rozwijanie specyfikacji WCAG stoi pod znakiem zapytania, jako, że WCAG odnosi się w swym założeniu tylko do stron internetowych opartych o język HTML i jest obecnie tylko jednym z rozdziałów ARIA, natomiast ARIA samo w sobie rozszerza pojęcie strony internetowej do „złożonej aplikacji internetowej”. Zatem badanie systemu, który w pełni wdraża i wykorzystuje ARIA dalece wykracza poza ramy oceny jego dostępności przy pomocy specyfikacji WCAG 2.0. Specyfikacja ARIA stanowi bowiem zestaw atrybutów, za pomocą których można nadać semantyczne znaczenie niesemantycznym elementom HTML, bądź też zmienić semantyczne znaczenie elementów, które zostały “przerobione” przy użyciu Java Scriptu na komponenty służące do innych celów, niż jest to opisane w dokumentacji HTML. Dzięki atrybutom ARIA możliwe jest uzupełnienie drzewka dostępności przeglądarki internetowej o dodatkowe informacje na temat właściwości tych elementów, a co za tym idzie przekazanie tych informacji technologiom asystującym. Efekty działania atrybutów ARIA są niewidoczne dla osób niekorzystających np. z czytników ekranu – strona internetowa, która nie używa ARIA będzie wyglądać dokładnie tak samo, jak używająca atrybutów ARIA. Zmieni się za to jej funkcjonalność i użyteczność z punktu widzenia osób korzystających z czytników ekranu. System oparty o ARIA jest zatem w pełni dostępny dla użytkowników niepełnosprawnych i to w stopniu znacząco wyższym, niż przewiduje to specyfikacja WCAG 2.0, choć formalnie może być całkowicie niezgodny z WCAG 2.0, która to specyfikacja nie przewidziała wychodzenia poza język HTML. I to jest właśnie najważniejsza zmiana wprowadzona nową ustawą.

Aplikacja Terminy leczenia NFZ

Dziś mamy dla was coś szczególnie przydatnego – bezpłatna aplikacja Terminy leczenia NFZ, dostępna dla komputerów z systemem Windows 10 i telefonów z Androidem, pozwala sprawdzić najbliższy wolny termin leczenia w ramach pakietu świadczeń gwarantowanych Narodowego Funduszu Zdrowia. Aplikacja korzysta bezpośrednio z bazy kolejkowej NFZ udostępnianej poprzez API opracowane ze wsparciem UE i oferuje przeszukiwanie pełnego spektrum tej obszernej bazy dla terenu całej Polski – wyszukuje wolne miejsca i sprawdza terminy zarówno do lekarzy specjalistów, na zabiegi, badania diagnostyczne, jak i wolne miejsca w oddziałach szpitalnych.

Wyszukiwanie terminów to nie wszystko – można też bezpośrednio skontaktować się z wybranym szpitalem lub przychodnią oraz sprawdzić, czy dana placówka oferuje parking, windę, udogodnienia dla osób niepełnosprawnych itp.

 

 

Android Q - kompatybilność zachowana

No i jest – pierwsza wersja deweloperska Androida Q, która w telefonach użytkowników zacznie pojawiać się w przyszłym roku. Obejrzeliśmy, sprawdziliśmy i spieszymy z informacjami co nowego. W kwestii kompatybilności Waszych aplikacji wyprodukowanych dla Androida 5.0 Lollipop i nowszych nie musicie się niczym martwić – nie znaleźliśmy żadnych problemów z kompatybilnością i nic nie wskazuje na to, aby w kolejnych wersjach deweloperskich, aż do wydania ostatecznego miały się takowe problemy pojawić. W gruncie rzeczy Android Q nie wnosi wiele w stosunku do obecnej wersji Androida P – Pie. Jest to raczej zestaw usprawnień interfejsu użytkownika, jak cokolwiek co mogłoby wpłynąć na funkcjonalność, czy kompatybilność istniejących aplikacji. Z najważniejszych zmian:

  • Android Q pozwala zmieniać motywy systemu – kolory akcentowe, czcionki, kształty ikon. Dodaje też motyw ciemny, który może wymuszać ciemny motyw dla zewnętrznych aplikacji o ile te takowy posiadają. Warto zatem w kolejnych aktualizacjach własnych aplikacji zadbać o dodanie do nich night mode.
  • Przewidywany czas pracy na aktualnym naładowaniu akumulatora jest pokazywany na pasku szybkich ustawień.
  • Można dzielić się szczegółami o sieci Wi-Fi za pomocą kodu QR.
  • Android Q wprowadza natywny tryb pulpitu po podłączeniu zewnętrznego monitora.
  • Dodano funkcję nagrywania ekranu.

Nieco ciekawsze, aczkolwiek też nie rewolucyjne, zmiany dodano „pod maską” i mają one znaczenie jeśli planujecie rozwijanie swojej aplikacji lub produkcję nowej. Są to funkcje dostępne dla programistów, zatem ich użycie można uwzględniać podczas projektowania aplikacji:

  • Dostępne są dodatkowe informacje z aparatów – głębia obrazu i poszczególnych obiektów na ujęciu.
  • Wsparcie dla składanych smartfonów.
  • Dodatkowe ustawienia dla urządzeń IoT (Internet of Things – internet rzeczy).