Tab bar controller navigation controllerin alla?

[DJKyykkae]

Tästä näyttää olevan paljon keskustelua netissä, joten nyt kaipailisin teiltä erityisesti henkilökohtaiseen kokemukseen perustuvia näkemyksiä yksioikoisen "kyllän" tai "ein" sijaan.

Apple näyttäisi haluavan, että tab baria käytettäisiin ehdottomasti vain applikaation päätason navigointielementtinä, eikä koskaan navigaatiohierarkian alemmilla tasoilla. Jos siis vaikuttaisi siltä, että loogisin ja sopivin navigointityyli omalle applikaatiolle olisi seuraavanlainen, onko kyse väistämättä virheellisestä ajattelusta softan toimintalogiikassa?

Nav controller
-> jonka päätasona olisi table view jossa luetellaan aiheen pääkategoriat
-> sen alatasona table view, jossa luetellaan valitun kategorian sisältämät elementit, ja tältä alatasolta edelleen detail disclosure buttonia painamalla päästäisiin
-> valittua elementtiä käsittelevään tab bar -näkymään, jossa kyseisestä elementistä olisi sitä eri näkökulmista käsitteleviä inforuutuja, joiden välillä siis navigoitaisiin alalaidan tabeja täppäilemällä

Tab bar -näkymän käyttäminen päätasolla ei tule tässä tapauksessa kyseeseen, koska tabeille ei ole mitään mielekästä käyttöä ennen kuin jokin yksittäinen kategorian elementti on selattu esiin. Toisekseen tab barin kuvake- ja tekstiselite -yhdistelmä vaikuttaisi käyttäjäystävällisimmältä tavalta kuvailla elementtiä koskevia infosivuja. Mutta olisiko silti "iPhonemaisempaa" käyttää esimerkiksi tavallista footer baria pelkkine kuvakkeineen tai sitten segmented control -napeilla ja pelkillä tekstiselitteillä varustettuna? Tämä näyttäisi olevan tapana ainakin Applen omissa applikaatioissa vastaavankaltaisissa tilanteissa...

[mpmartik]

Apple todellakin haluaa, että TabBar on iOS sovelluksissa joko ylimmän tai toiseksi ylimmän tason view controller (UISplitViewController voi sisältää UITabBarControllerin, mutta tällä hetkellä se on ainoa poikkeus.)

Jos tuosta poikkeaa, niin ensimmäinen riski on että Apple hylkää sovelluksen. Toinen on, että ihmiset eivät osaa käyttää sovellusta oikein. Sinällään kuvailemasi kaltainen toimintalogiikka ei ole millään tapaa väärä tai huono, monessakin asiassa hierarkia muodostuu noin. Applen perusratkaisu on käyttää navigation controlleria, jolloin sinun tapauksessasi siis navigaatioon tulisi yksi taso lisää. Ei välttämättä hyvä, koska se lisää edestakaisin sahaamisen määrää. Toinen, minusta harkitsemisen arvoinen vaihtoehto olisi käyttää UIPageControlia eri näkökulmien välillä siirtymiseen, tässä tapauksessa sinun pitäisi varmaan luoda oma indikaattori joka kertoo missä näkymässä ollaan ja mitä muita näkymiä on.

Muitakin vaihtoehtoja tab barille on, esimerkiksi mainitsemasi UISegmentedControl (jota Apple käyttää vastaavaan tarkoitukseen). Myös UIScrollView + pagination voisi toimia.

En nyt ikävä kyllä ehkä osannut ihan vastata kysymykseesi, mutta toivottavasti tästä jotain apua oli.

[DJKyykkae]

Kyllä vain, kiitos. Juuri tällaista pohdintaa ja näkökulmia juuri kaipasinkin, ei pelkkää jaa/ei/poissa -äänestystä.

[Virgo]

Tekemässäni ajopäiväkirjassa on tehty juurikin näin: Etusivulta valitaan auto, ja vasta tästä avautuvassa näkymässä on tabbar. Tiedän, että se ei ole Applen suosituksien mukainen, mutta omasta mielestäni toimii loogisesti. Ohjelma on appstoressa myynnissä, joten ei Apple sitä ainakaan hylkää sen perusteella.

Valmis UITabViewController ei toiminut kunnolla navigointikontrollerin alla (en nyt muista enää, mitä ongelmia siitä tuli), joten jouduin tekemään oman kontrollerin tuon tabbarin toiminnallisuuden toteuttamiseksi. Lisää työtähän tämä aiheutti. Sellainen muutos minulla on myös, että kun auto on valittu, ja siirrytään navigointikontrollerissa eteenpäin, ei yläkulmassa näytetä back nappia. Tällöin tila vapautuu muuhun käyttöön. Kun käyttäjä haluaa vaihtaa toiseen autoon, valitaan "Muut" välilehti, ja sieltä "Vaihda ajoneuvoa" nappi. Tuo ei välttämättä ole käyttäjäystävällisyyden kannalta paras ratkaisu, ja olen miettinyt vaihtoehtoisia tapoja toteutukselle.

Näkökulmani on, että jos tuo mielestäsi toimii hyvin navigointiratkaisuna, niin Applen puolelta siihen ei vaikuttaisi tulevan vastustusta. Olen törmännyt useampaan ohjelmaan appstoressa, jossa on tällainen toiminnallisuus.

[DJKyykkae]

Kiitos myös Virgolle, näkemyksenne ovat erittäin arvokas apu omia UI-päätöksiä pähkäillessä. Juu, kyllä tuota mallia näkyy silloin tällöin, jopa Wordpress-applikaatiossa, joka ei mielestäni tosin ole kovin hyvä esimerkki: tab bar on vähän hämäävästi navigointihierarkian keskellä, ja sisemmäs navigoitaessa tilalle skrollaa tavallinen footer, joka on ärsyttävästi juuri muutaman pikselin verran erikorkuinen, ja tabista riippuen ilman kummempia perusteluja joko vakiovärinen tai musta. App Storessa sekin silti on, joten ei siellä hirveän ortodoksisia tunnuta käytännössä tämän suhteen olevan.

Olennaisin kysymys ei taidakaan olla "saako" niin tehdä, vaan mistä syistä Apple ei haluaisi niin tehtävän. Jos ajatellaan vaikka OS X:n puolella esimerkiksi Dock-paneelia, jossakin omassa softassa voisi tuntua kätevimmältä käyttää juuri sellaista toiminnallisuutta softaikkunan laidassa oman UI:n ominaisuutena, mutta eihän se oikein OS X:maista olisi – Dock on kuitenkin Dock. Applella varmaan yritetään pitää hommaa kasassa niin että iOS-puolelle syntyisi samantyyppinen näppituntuma siitä "mikä iOS on", jolloin tällaisia mobiilipuolen "karkuteille lähteneitä Dockeja" ei pääsisi syntymään ja sekoittamaan pakkaa. iPhone/iPad-ympäristö on kuitenkin edelleenkin niin uusi, että "standardoitu" käyttäjäkokemus on sille puolelle vasta muodostumassa. Mutta Applellakin varmaan pohditaan tosissaan tilannetta, jos aletaan huomaamaan, että johdonmukaisia ja perusteltuja UI-malleja alkaa vaan luonnostaan muodostumaan heidän alkuperäisten kaavailujensa vastaisesti.

Kahden vaiheilla ollaan edelleen... ehkäpä kokeilen ensin, millainen käyttökokemus syntyy "Applemaisella" lähestymistavalla – taidan kokeilla footeria pelkillä kuvakkeilla ja selventää eri osioita sitten Titlessä... ainakin näin alkuun. Jos homma tuntuu ehdottomasti vaativan Tab Baria, siirryn ehkä myöhemmin siihen.