Proč se mi iOS používá hůř než Android

V září loňského roku jsem si kvůli testování pořídil iPod Touch 4G (v podstatě iPhone 4, jen neumí volat a není to taková cihla) a byl jsem zvědavý, jak se ovládá ikona v oblasti UI / UX, průkopník všech dobře použitelných smartfounů. Snažil jsem se iOS používat asi 14 dní a v tomto zápisku bych chtěl shrnout, co se mi na tom nelíbilo a proč jsem daleko spokojenější s Androidem.

Vím, že tento článek bude bodnutím do vosího hnízda, protože většina majitelů nedá na svůj iPhone dopustit (a platí to samozřejmě i pro další zapálené vlastníkyjiných OS, mě nevyjímaje), ale hlavní motivací bylo právě to – o iOS se mluví v podstatě jen pozitivně a tolik výhrad pohromadě budete jinde hledat jen stěží :) Pokud rádi přemýšlíte o UX, možná v článku najdete pár námětů k zamyšlení nezávisle na tom, jakému mobilnímu systému fandíte. Celý příspěvek

Pit of Success a spouštění skriptů v PowerShellu

Pokud bych si měl vybrat jeden jediný princip návrhu prakticky čehokoliv (uživatelského rozhraní, programátorského API atd.), kterým bych doporučil se řídit, byl by to dost možná The Pit of Success. Kupodivu, podle Googlu se zdá, že tento princip není pod tímto jménem moc známý – každá blbost má dneska stránku na Wikipedii, ale toto ne, a dotaz “pit of success ux” dokonce nevrací žádný relevantní dotaz (UXáři, vy tento pojem nepoužíváte?). Můžete si tak počíst hlavně na dvou starších blog postech od Brada Abramse a Jeffa Atwooda, ale v zásadě je velmi jednoduchý.

Co je tedy onen Pit of Success neboli “jáma úspěchu”? Zhruba toto:

pit-of-success

Místo abyste se museli snažit o dosažení úspěchu, to něco (uživatelské rozhraní, API, golfová jamka) je navrženo tak, abyste do úspěchu “spadli” skoro i proti své vůli. V praxi to znamená, že nad úkoly nemusíte moc přemýšlet, prostě uděláte první, co vás napadne, a ono to většinou bude správně.

Princip je to velmi jednoduchý, přesto pořád narážím na software, jehož autoři evidentně na Pit of Success nemysleli nebo pro ně minimálně nebyl prioritou. Jedním takovým příkladem je PowerShell, respektive způsob, jakým se v něm spouštějí skripty.

Jakožto začátečník jsem si otevřel tutoriál na webu Microsoftu, který se v odkazovaném dílu věnuje spouštění skriptů. Už trochu zarážející je, že pro tak základní věc musí existovat samostatný článek v jinak velmi letmé sérii tutoriálů, ale budiž. Abyste stránku nemuseli číst, vytáhnu z ní občas drobné, ale v souhrnu důležité informace:

  • Na výchozí instalaci PowerShellu / Windows nejdou skripty (soubory s příponou *.ps1) spustit vůbec.
  • Abyste si spustili svůj první skript, musíte nastavit ExecutionPolicy. Buďto slepě na nějakou uvedenou hodnotu, nebo si můžete počíst v tématu nápovědy About_Signing.
  • Skript nejde spustit poklepáním v průzkumníku jako třeba BAT soubory. Poklepání na PowerShell skript otevře Notepad nebo podobný editor.
  • Ani když jste v konzoli PowerShellu ve správném adresáři, napsání "MyScript.ps1" nepovede k jeho spuštění.
  • Musíte zadat .\MyScript.ps1, ale bacha, tečka není aktuální adresář, spustí vyhledávání ve všech adresářích, které máte v systémové proměnné PATH. Vypadá to, že spustit skript z aktuálního adresáře nejde jinak, než zapsáním jeho celé, absolutní cesty (C:\...).
  • Pokud cesta ke skriptu obsahuje mezeru, musíte ji uzavřít do uvozovek. Současně ale v tomto případě musíte před cestu napsat speciální znak &, jinak spuštění opět nezafunguje.
  • Pokud spouštíte skript mimo konzoli PowerShellu pomocí powershell.exe c:\scripts\test.ps1, můžete přidat parametr -noexit, aby zůstalo okno otevřené. Ale pozor, tento parametr musí být hned za voláním powershell.exe, jinak bude ignorováno.
  • Pokud chcete PowerShell skripty spouštět třeba po přihlášení do Windows, musíte si vytvořit VBScript soubor a teprve z něj zavolat powershell.exe atd.

Příkazová řádka sice není můj svět, ale pokud si pamatuji, v žádném jiném shellu, ani na Windows, ani při letmém kontaktu s Linuxem, jsem nezažil, aby se o spouštění skriptů napsalo tolik textu nebo že by kolem toho existovalo tolik podrobností. Jinými slovy, PowerShell mi na první pohled připadá jako skriptovací technologie, kde se autoři vážně snažili, aby bylo spouštění skriptů co nejtěžší.

Zcela nepochybně pro každý z bodů existuje nějaký racionální důvod (tak se koneckonců software v Microsoftu dělá) a řadu těch důvodů si dokážu domyslet (bezpečnost apod.), ale i tak mám pocit, že někdo při návrhu spouštění skriptů v PowerShellu zanedbal důležitý pohled koncového uživatele. Pokud 99% lidí udělá to, že po spuštění PowerShellu jde na Google, najde rychle něco o ExecutionPolicy a nastaví ji na Unrestricted, tak je něco špatně.

Nechci, aby článek vypadal jako nějaká debata nad detaily implementace PowerShellu, nejsem k tomu povolaný a ani to není pointou článku. PowerShell se mi ve skutečnosti moc líbí a v mnoha věcech ho považuji za nejpokročilejší shell současnosti, jen je potřeba sžít se s jeho přístupem ke spouštění skriptů, a věci, které používám nejraději, žádnou takovou sžívací fázi nepotřebují. Navíc, a to už není prkotina, pokud se něco elementárního dělá u libovolného software nesnadno, může to odradit od jeho používání, a v případě PowerShellu mám pocit, že k tomu dochází – většina OSS projektů používá init.bat nebo build.bat namísto init|build.ps1. Možná je to proto, že BAT spustí každý, zatímco spuštění PowerShell skriptu je, řekněme, netriviální.

Proto, když něco dělám, vždycky se snažím “jámu úspěchu” vybagrovat tak velkou, jak jen to jde.