आधुनिक iOS नेविगेशन पैटर्न
(frankrausch.com)- iOS ऐप नेविगेशन में hierarchy, overlay और view के अंदर के flows को स्पष्ट रूप से अलग करना चाहिए, ताकि यूज़र अपनी मौजूदा जगह और वापस जाने का रास्ता समझ सके
- Structural patterns Drill-Down, Flat, Pyramid और Hub-and-Spoke में बंटते हैं; tree browsing, tab-based segmentation, sibling screens के बीच जाना और hub पर लौटना—इन सबमें screen transition का अर्थ अलग होता है
- Overlay ध्यान खींचने का साधन है, लेकिन modal है या नहीं और friction level के आधार पर पीछे वाली screen कितनी block होगी और यूज़र को क्या action करना होगा, यह बदलता है
- Embedded navigation किसी खास view या modal के अंदर होना चाहिए, और इसे ऐसे design करना चाहिए कि state change या Step-by-Step flow hierarchy में movement जैसा न लगे
- Tabs predictable होने चाहिए और Cancel को data तुरंत discard नहीं करना चाहिए; iOS apps में arbitrary movement की बजाय स्पष्ट hierarchy, state और modal boundaries बनाए रखना बेहतर है
iOS नेविगेशन के तीन axes
- iOS apps आम तौर पर कई levels वाले fixed hierarchy tree से बने होते हैं
- Structural navigation यूज़र को यह समझने में मदद करता है कि वह कहां से आया, hierarchy में कहां है, और अपनी मूल जगह पर कैसे लौटेगा
- Overlay किसी भी context के ऊपर दिखाई दे सकता है, और दूसरे overlay के ऊपर भी layered दिख सकता है
- Modal overlay यूज़र की action के बिना गायब नहीं होता और पीछे की interface को block करता है
- Non-modal overlay ऐप को block नहीं करता
- Embedded navigation को iOS के structural और spatial model के मुताबिक किसी खास view या modal overlay के अंदर शामिल करना उपयुक्त होता है
Structural navigation patterns
-
Drill-Down
- Drill-Down information की tree structure को step-by-step lists के रूप में explore करने का pattern है
- Animation transition columns के बीच horizontal movement का संकेत देता है
- दाईं ओर जाना tree hierarchy में और deeper level में जाने की action है
- बाईं ओर जाना upper level पर लौटने की action है
- Drill-Down navigation modeless structure है, इसलिए save करना है या नहीं जैसे सवाल hierarchy exploration को interrupt नहीं करते
- Navigation Bar current screen का title दिखाता है, और list row का Disclosure indicator यह दिखाता है कि deeper hierarchy में जाया जा सकता है
- Back button upper level पर लौटने का स्पष्ट रास्ता है, और space हो तो सामान्य “Back” की जगह parent screen title को label के रूप में इस्तेमाल करना बेहतर है
- Screen के left edge से right की ओर swipe करना Back button जैसा ही काम करता है
- Custom implementations को iOS standard की तरह screen-edge pan gesture से controlled, interactive और cancellable transitions देने चाहिए
- Right-to-left पढ़ी जाने वाली languages में navigation direction और control placement reading direction के मुताबिक mirrored होते हैं
- Tree structure को database filtering के लिए dynamically बनाया जा सकता है
- Music app में Artist, Album, Genre जैसे अलग-अलग starting points से उसी album तक Drill-Down किया जा सकता है, और search interface भी साथ इस्तेमाल हो सकता है
- Drill-Down, macOS Finder style Miller columns का one column per screen variant है
-
Flat
- Flat pattern hierarchy को root level पर divide करता है और tab bar से दिखाता है
- iPad पर इसे sidebar के रूप में दिखाया जा सकता है
- Tab bar items ऐप की core features के आधार पर चुने जाते हैं और user expectations तथा ऐप के बारे में mental model बनाते हैं
- Tab bar items में से एक हमेशा selected रहता है, और active selection तय करता है कि ऐप के main content area में क्या दिखेगा
- Current selected tab bar item को user interaction के बिना programmatically नहीं बदलना चाहिए, और interface के किसी दूसरे button को tap करने जैसे indirect तरीके से भी नहीं बदलना चाहिए
- Tab bar, modal sheet से अस्थायी रूप से ढकने के मामलों को छोड़कर, ऐप की पूरी screen में लगातार दिखता रहता है
- Tabs को filter की तरह या music, video, photo libraries जैसी बड़ी content collections के अलग-अलग entry points के रूप में इस्तेमाल किया जा सकता है
- हर section अपनी sub-hierarchy की navigation state बनाए रखता है
- Tab bar items को predictable तरीके से behave करना चाहिए; उन्हें sheet खोलनी या कोई action execute नहीं करना चाहिए
- Hamburger menu tab bar के contrast में hidden navigation method है
- अगर पूरी navigation interface एक छोटे icon के पीछे छिप जाए, तो discoverability घटती है
- 2015 के आसपास iOS में यह trend में था, लेकिन tab bar कहीं ज्यादा discoverable है यह research सामने आने के बाद app makers ने Hamburger menu छोड़ दिए
- Flat pattern hierarchy को root level पर divide करता है और tab bar से दिखाता है
-
Pyramid
- Pyramid pattern parent screen पर लौटे बिना same hierarchy level के sibling views के बीच तेजी से जाने देता है
- Media apps में horizontal swipe gesture अक्सर sibling views के बीच movement के लिए इस्तेमाल होता है
- Buttons भी इस्तेमाल किए जा सकते हैं, जैसे iOS Mail app के Next Message और Previous Message chevron buttons
- iOS Photos app Pyramid pattern का उदाहरण है
- Photo पर tap करके उसे full screen में खोलने के बाद left/right swipe करके adjacent images देखी जाती हैं
- छोटी collections में page control का उपयोग करके total item count और current item की sibling position visualize की जाती है
- iOS App Switcher apps के बीच तेजी से जाने वाला Pyramid pattern implement करता है और Home screen से होकर जाने की तुलना में तेज navigation देता है
-
Hub-and-Spoke
- Hub-and-Spoke pattern तब उपयुक्त है जब hierarchy के top level पर आपस में unrelated बड़ी collections हों
- Full-screen child views के बीच switch करने के लिए हमेशा पहले hub पर लौटना पड़ता है
- iOS Home screen installed applications की collection है और operating system की भरोसेमंद neutral state की तरह काम करती है
- Screen के bottom में Home indicator सीखने में आसान और हमेशा available escape route है, जो परिचित Home screen interface पर वापस ले जाता है
- यह pattern app के अंदर बहुत कम इस्तेमाल होता है
- Operating system level पर applications के बीच जितनी strong separation होती है, app के अंदर उतनी strong separation की जरूरत शायद ही कभी होती है
Overlay navigation
-
High-Friction Modal
- High-Friction Modal overlay, जैसे sheet या कई actions वाला alert dialog, यूज़र के decision लेने तक पीछे की screen को block करता है
- Email compose करने या calendar event बनाने में Done या Send से आगे बढ़ना, या Cancel से मन बदलना, जैसी choice चाहिए होती है
- Cancel button को किसी state या data को सीधे discard नहीं करना चाहिए
- Modal sheet में Cancel tap करते समय safety net के रूप में हमेशा additional confirmation dialog दिखाना चाहिए
- Alert dialog में Cancel कभी भी destructive action नहीं होना चाहिए
- Modal, email compose करने या calendar event add करने जैसे specific और independent task को पूरा करने पर focus करता है
-
Low-Friction Modal
- Low-Friction Modal sheet, menu, popover की तरह app के बाकी हिस्से को block करता है, लेकिन “दो में से एक” decision की मांग नहीं करता
- इसे आसानी से dismiss किया जा सकना चाहिए, जैसे close button दबाकर या sheet को नीचे swipe करके
- context menu या popover के बाहर tap करने पर यह गायब हो जाता है
- सिर्फ OK button वाला alert dialog dismiss करना आसान है, लेकिन low friction का मतलब no friction नहीं है
- Single-action alerts को जितना हो सके avoid करना चाहिए
- ये user flow को interrupt करते हैं, और कई बार इन्हें inline text या non-modal notification से replace किया जा सकता है
-
Non-Modal
- Non-Modal overlay screen के एक हिस्से को cover करता है, लेकिन पीछे की interface को block नहीं करता
- Non-blocking होने के कारण इसमें friction बहुत कम या नहीं होता
- यह operating system notification की तरह app के बाहर के triggers पर response में दिखाई दे सकता है
- अगर यह automatically disappear होता है, तो इसे minimal interruption के साथ एक नजर में देखी जा सकने वाली peripheral information देनी चाहिए
- Temporary non-modal overlay में optional interaction हो सकता है
- Notification tap करना, या volume indicator गायब होने से पहले उसे swipe करके volume बदलना संभव है
- जो overlay बाकी application को block नहीं करता और न ही अपने आप appear/disappear होता है, उसे palette कहा जा सकता है
Embedded navigation
-
State Change
- एक view की कई states हो सकती हैं
- List view, navigation hierarchy में position बदली हुई लगे बिना empty, loading, populated states रख सकता है
- यह सुनिश्चित करना चाहिए कि state change वास्तव में hierarchical या modal तो नहीं है
- In-place state change में full-screen transition से बचना चाहिए
- Examples में list का edit mode, web browser interface, pannable street map और zoomable image शामिल हैं
- View options, user की location बदले बिना सिर्फ content display का तरीका बदलते हैं
- list view और thumbnail view के बीच switch करना उसी context की उसी information को अलग visualizations के रूप में toggle करना है
-
Step-by-Step
- Step-by-Step pattern guided tour, setup flow, onboarding tutorial जैसी screens की series को linear flow में जोड़ता है
- Online store checkout जैसे बहुत सारा data enter करने वाले process में भी कई steps चाहिए होते हैं
- Sequence के अंदर आगे-पीछे जाना hierarchy level को नहीं बदलता, और यही बात इसे Drill-Down pattern से अलग करती है
- Step-by-Step sequence को modal overlay के अंदर रखकर दिखाना बेहतर है
- इस context में Back button का purpose hierarchical Drill-Down के Back button से अलग है
- Process आम तौर पर Done या Close button से पूरा होता है, और यह button शामिल modal को भी dismiss करता है
- चुने गए options के हिसाब से steps की संख्या और path बदल सकते हैं
- Wizard and assistant इस pattern के दूसरे नाम हैं
- Step-by-Step process boring लग सकता है
- अगर उम्मीद है कि user इसे अक्सर करेगा, तो कई steps को एक view के भीतर अलग states में combine करके information resolution बढ़ाने और context switching घटाने पर विचार किया जा सकता है
-
Content-Driven
- Content-Driven navigation वह तरीका है जिसमें hyperlink या button user को किसी दूसरी page या view पर instantly ले जाता है
- Browser की web navigation इसी तरीके से काम करती है
- iOS apps में hypertext दिखाने वाले apps, immersive games और समान non-linear content को छोड़कर इस pattern से बचना बेहतर है
- अगर app में hypertext content दिखाना जरूरी हो, तो इसे back/forward controls वाले browser interface के अंदर शामिल करने पर विचार किया जा सकता है
- Independent browser interface की state change, application hierarchy में unexpected location change की तुलना में समझने में आसान होती है
- Apps के बीच जाने के लिए links इस्तेमाल किए जा सकते हैं
- Deep Links URL scheme या domain से जुड़े Universal Links का इस्तेमाल करके user को किसी app या website से दूसरे app की deep hierarchy में ले जाते हैं
References
- Apple WWDC 2022: Explore navigation design for iOS
- Jenifer Tidwell, Designing Interfaces, Third edition, O’Reilly, 2020
- Apple Human Interface Guidelines / Navigation, Archive.org, 2022-01-19
3 टिप्पणियां
Hacker News की राय
यह बात पहले भी बहुत कही जा चुकी है, लेकिन Apollo ने इस पैटर्न का अच्छा इस्तेमाल किया था, और यही उन कई कारणों में से एक था जिनकी वजह से वह Reddit के आधिकारिक ऐप से कहीं बेहतर था
नेविगेशन, जेस्चर और व्यवहार एकसमान थे, और यह कोई मुश्किल अवधारणा भी नहीं है। बस इतना है कि इसे निभाने लायक ध्यान देना पड़ता है, लेकिन बहुत से ऐप ऐसा नहीं करते, जो काफी निराशाजनक है
यह कुछ वैसा है जैसे सुपरमार्केट समय-समय पर शेल्फ़ की सजावट बदलते रहते हैं। अगर नेविगेशन, जेस्चर और व्यवहार एकसमान हों, तो उपयोगकर्ता बहुत कुशलता से अपनी मनचाही चीज़ लेकर जल्दी बाहर निकल सकता है
मैं 30 हज़ार लोगों वाले एक subreddit को चलाता हूँ, इसलिए मुझे फ़ोन पर Reddit इस्तेमाल करना आना चाहिए, लेकिन यह लगभग असंभव है। हर काम के लिए बहुत ज़्यादा steps चाहिए होते हैं, और मैं यह भी नहीं समझ पाता कि इस समय हूँ कहाँ, इसलिए यह पूरी तरह बेकार लगता है
मैंने कुछ साल पहले ही Reddit छोड़ दिया था, लेकिन यह घटना आख़िरी कील साबित हुई
मुख्य स्क्रीन पर लौटने में इतनी मानसिक ऊर्जा लगती है कि मैं बस ऐप को force quit करके फिर से खोल देता हूँ
कुछ ही स्तर नीचे जाने के बाद पहली स्क्रीन पर लौटने के लिए वहाँ तक पहुँचने तक बार-बार swipe करना या back दबाना पड़ता है, जो काफ़ी झंझट वाला है। शायद कोई ऐसा जादुई जेस्चर हो जिसे मैं नहीं जानता
“iOS नेविगेशन पैटर्न” जैसा वाक्य सुनते ही मैं सिहर जाता हूँ। वहाँ कोई पैटर्न है ही नहीं, और Android की तुलना में यह iOS की सबसे बुरी चीज़ों में से एक है
Android में back जाना आसान है और उसके कई अर्थ हो सकते हैं। मैं एक साल से ज़्यादा समय से iOS इस्तेमाल कर रहा हूँ, और मुझे दो back “patterns” में से एक को आँख बंद करके आज़माना पड़ता है, फिर ऐसे बटन को ढूँढना पड़ता है जो हाथ की पहुँच से बाहर हो। और कभी-कभी उससे भी काम नहीं बनता
इसे developers पर नहीं छोड़ना चाहिए; इसे operating system स्तर पर ठीक करना चाहिए। developers नहीं चाहते कि उपयोगकर्ता ऐप के किसी हिस्से से बाहर जाएँ। उदाहरण के लिए Instagram Reels में back करके देख लीजिए
back button क्या करेगा, इसमें ज़रा भी एकरूपता नहीं है। एक developer होने के बावजूद मैं भी कई स्थितियों में सोचता रह जाता हूँ कि back को क्या करना चाहिए। क्या यह पिछली स्क्रीन पर जाना चाहिए, या drill-down नेविगेशन में एक स्तर ऊपर? कभी दोनों एक ही होते हैं, लेकिन हमेशा नहीं
कभी यह नेविगेशन संरचना में एक स्तर ऊपर जाता है, कभी पिछली स्क्रीन पर, कभी dialog बंद करता है, और कभी ऐप ही बंद कर देता है। संदर्भ के अनुसार कोई भी व्यवहार संभव है, और अगर कई विकल्प लागू हों तो यह स्पष्ट नहीं होता कि कौन-सा होगा। इसका पता लगाने का एकमात्र तरीका है दबाकर देखना कि क्या होता है
मुझे अस्पष्ट user interface elements से नफ़रत है। जब मैं किसी चीज़ पर click करूँ, तो मुझे पता होना चाहिए कि कौन-सी action चलेगी
यह बहुत गहरी एकरूपता पैदा करता है, जिससे नेविगेशन बोझिल नहीं लगता। काश iOS में भी यही चीज़ इसी तरह built-in होती
activity stack ऐप्स के पार काम करता है, इसलिए भले ही कई ऐप मिलकर एक काम संभाल रहे हों, back gesture हमेशा आपको ठीक पिछली स्क्रीन पर वापस ले जाता है
कभी यह ऊपर बाएँ होता है, कभी नीचे बाएँ, कभी नीचे दाएँ, और शायद कुछ ऐप इसे कहीं और भी रखते होंगे
Android में operating system back button होता है, जो एक हाथ से इस्तेमाल करते समय भी हमेशा पहुँच में रहता है। यह तरीका कहीं बेहतर है
उदाहरण के लिए अगर आप किसी view की सामग्री बदल सकते हैं, तो आप सारी सामग्री हटाकर उसकी जगह बिल्कुल नई सामग्री भी रख सकते हैं। अगर यह उपयोगकर्ता की किसी क्रिया के बाद होता है, तो यह व्यवहारिक रूप से “नई स्क्रीन पर जाना” जैसा ही है। लेकिन अगर developer प्रस्तावित operating system API call
createNewViewका उपयोग करने के बजाय मौजूदा view की सामग्री ही बदल दे, तो operating system-स्तर का gesture काम नहीं करेगाहालाँकि Apple review pass कराने के लिए इस operating system API का उपयोग अनिवार्य कर सकता है। फिर भी क्या “पीछे जा सकने वाला नया view” है और क्या “सिर्फ़ सामग्री बदला हुआ पुराना view”, यह कुछ हद तक व्यक्तिपरक ही रहेगा
यह contacts, applications, vertical items, horizontal items और नीचे अन्य items दिखाता है, और वह भी तभी जब आपको यह पता चल जाए कि इसे ऊपर की ओर खींचना भी है। हर ऐप में इसकी जगह भी अलग होती है, और icon का “share” या “copy/paste” से कोई साफ़ संबंध नहीं होता
जो लोग smartphone के साथ बड़े हुए हैं, वे हमेशा की तरह इसके अनुरूप ढल सकते हैं। अगर इसकी शुरुआत के समय आपकी उम्र 40–50 से ज़्यादा नहीं थी, तो आम तौर पर आप ढल सकते हैं। ज़्यादातर आधुनिक चीज़ें बहुत खराब तरह से design की गई हैं और अक्सर अस्थिर भी रहती हैं। AppleTV भी ऐसा ही है, और चाहें तो Wi‑Fi password बदलने की बात भी कर सकते हैं। bugs से बचने के लिए इसकी ज़रूरत पड़ती है, लेकिन मुझे समझ नहीं आता कि power toggle दबाने पर यह reboot क्यों नहीं करता
यह पर्याप्त रूप से संबंधित है या नहीं, पता नहीं, लेकिन Mac और अब iPadOS(https://useyourloaf.com/blog/ipad-customizable-toolbars/) में built-in toolbar controls काफ़ी उच्च स्तर का customization सपोर्ट करते हैं
इसे Finder समेत कई native apps में आज़माया जा सकता है
शक्तिशाली built-in widgets Mac desktop का एक कम आंका गया हिस्सा हैं, और SwiftUI के हावी होने के साथ यही बात मुझे चिंतित भी करती है। iOS में भी यह बड़ा फ़ायदा है, लेकिन apps अक्सर अपने ही design चढ़ाने की कोशिश करते हैं, इसलिए यह अपेक्षाकृत कम दिखता है
लेकिन शायद मैं ग़लत याद कर रहा हूँ, मुझे लगता है पहले iOS apps tab bar customization को default रूप से सपोर्ट करते थे। यह toolbar से अलग तो है, लेकिन tabs का क्रम और वास्तव में कौन से tabs दिखें, इसे बदलने देना built-in toolbar customization का एक वैचारिक समकक्ष लगता था। लेकिन कई सालों से यह देखा नहीं
दस्तावेज़ के अनुसार यह अभी भी मौजूद है। जानना चाहता हूँ कि क्या किसी को कोई app पता है जो अब भी यह pattern इस्तेमाल करता हो: https://developer.apple.com/documentation/uikit/uitabbarcont...
खैर, tab bar बढ़िया है। मैंने जिन ज़्यादातर Apple TV apps का इस्तेमाल किया है, वे इसी तरीके का उपयोग करते हैं, और उसका consistent experience शानदार है
जब Facebook अभी ठीक-ठाक था, शायद iOS 7 के आसपास, मुझे याद है कि chat, feed, notifications, groups जैसी चीज़ों को इस तरह बदला जा सकता था
Apple के बाहर जो apps याद आते हैं, वे सब बहुत पहले मुश्किल से मिलने वाले hamburger menu पर चले गए
customization की संभावना अच्छी है, लेकिन custom implementations में यह लगभग कभी नहीं मिलती
UITabBarहमेशा से programmer के नज़रिए से भी customization के मामले में तकलीफ़देह रूप से सीमित रहा है, और user द्वारा उसे बदलने वाली दिशा में ध्यान देने वाले projects भी बहुत कम रहे हैंमुझे लगता है Apple ने उसकी appearance को इतना कड़ा बंद कर दिया कि आख़िरकार सबने उसे किसी और चीज़ से बदलना शुरू कर दिया
Apple Music के 2 tabs ऐसे हैं जिन्हें मैं सचमुच कभी इस्तेमाल नहीं करता। अच्छा होता अगर मैं सीधे playlists और albums पर जा पाता
यहाँ पहली बात, “drill-down navigation state-less है,” उलटी लगती है
screen N पहले किए गए काम पर निर्भर करती है, और वहाँ वापस भी जा सकते हैं, इसलिए यह बहुत stateful संरचना है। उपयोगी होने के लिए इसे वास्तव में internal state track करनी पड़ती है। उदाहरण के लिए list की contents N-1 state पर निर्भर होंगी, नहीं तो अनुभव बहुत ख़राब होगा
state-less UI तो एक single-step modal जैसी चीज़ होगी। या तो है या नहीं है। ख़ासकर अगर वह अस्थायी हो और उसे “resume” करने का कोई तरीका न हो, तो उसे और भी ज़्यादा state-less कहा जा सकता है
वर्षों से मैंने “stateful” शब्द का पूरी तरह अलग अर्थों में इस्तेमाल होने वाली काफ़ी चर्चाएँ देखी हैं, और हाल में तो बहुत अधिक। इसलिए मैं लगभग इस निष्कर्ष पर पहुँचा हूँ कि लगभग कोई भी इस शब्द के अर्थ पर एकमत नहीं है, और बहुत कम लोग इस बात से भी वाक़िफ़ हैं
मैं जानना चाहता हूँ कि आपके लिए stateful UI का क्या मतलब है। यह अंतर दिलचस्प है
iOS जैसी hierarchy में हर child का ठीक एक parent होना चाहिए, इसलिए सिर्फ़ current page पता हो तो भी मालूम हो जाता है कि “back” button क्या करेगा। आप उस page पर जैसे भी पहुँचे हों, hierarchy में एक स्तर ऊपर parent page पर जाएँगे
Android जैसे activity stack में सिर्फ़ current page काफ़ी नहीं होता, यह भी जानना पड़ता है कि आप वहाँ पहुँचे कैसे। क्योंकि “back” button का मतलब history में पीछे जाना होता है
कई websites दोनों को सपोर्ट करती हैं। browser का back button stateful होता है और आपकी व्यक्तिगत history में चलता है, जबकि breadcrumb जैसी in-page navigation आम तौर पर state-less होती है, क्योंकि वह उस page तक पहुँचने के विशेष path पर निर्भर नहीं करती। बेशक अपवाद भी हैं। कई search interfaces में आप किसी item में जाते हैं और फिर page के अंदर की navigation से लौटते हैं तो parent page नहीं, बल्कि पिछला search term लौटता है, इसलिए उसे stateful कहा जा सकता है
यहाँ एक बात ग़लत ढंग से कही गई लगती है। “स्क्रीन के बाएँ किनारे से दाएँ swipe करना back button दबाने जैसा है” वाला हिस्सा
अगर इसे सीधे implement करें, तो यह swipe gesture नहीं बल्कि edge pan gesture होना चाहिए। यह उंगली के साथ चलने वाला और cancellable interactive pan होना चाहिए, नहीं तो इसका feel ग़लत लगेगा
बहुत बार ऐसा हुआ है कि मैं कुछ मन लगाकर टाइप कर रहा होता हूँ, और फ़ोन के किनारे को हल्का-सा छूते ही पूरा comment उड़ जाता है
कारण यह है कि left-handed लोग भी होते हैं। बाएँ हाथ के अंगूठे से यह न स्वाभाविक है, न आरामदेह। left-handed users के लिए दिशा उलटी भी नहीं की जा सकती। अगर पढ़ना बाएँ से दाएँ है, तो right swipe पीछे नहीं बल्कि आगे जाने जैसा लगता है
कुल मिलाकर मुझे swipe से navigate करना पसंद नहीं। iOS में तो यह ख़ास तौर पर बुरा है। नीचे से ऊपर swipe करने पर कोई menu ऊपर आ जाता है, जिसमें असल में महत्वपूर्ण चीज़ें होती हैं, लेकिन जब ज़रूरत हो तब मिलती नहींं, और web page scroll करते समय बार-बार ग़लती से activate हो जाता है
और व्यापक रूप से कहूँ तो iOS एक ऐसे डरावने, बेहिसाब जटिल operating system में बदल गया है जिसमें navigation करना दुःस्वप्न जैसा है, और लगता है Apple को फिर से UI/UX को गंभीरता से लेना चाहिए। मुख्य समस्या शायद यह है कि फ़ोन से अब इतने सारे काम करने की अपेक्षा की जाती है जिनके लिए वह शुरू से उपयुक्त नहीं था
https://sailfishos.org/
कुल मिलाकर मुझे यह iOS और Android से ज़्यादा सरल और बेहतर लगता है
जो लोग visual software के पहलू में कठिनाई महसूस करते हैं, उनके लिए यह सचमुच बहुत अच्छा resource है
diagrams और स्पष्ट व्याख्या शानदार हैं
Frank Rausch वही व्यक्ति हैं जिन्होंने बेहतरीन Wikipedia ऐप “V for Wiki” बनाया था
इसलिए जब वे iOS design और user experience के बारे में बात करते हैं, तो उसे सुनना बनता है
https://web.archive.org/web/20211223231349/https://v-for-wik...
मैं इसे रोज़ इस्तेमाल करता था, फिर एक दिन यह अचानक काम करना बंद कर गया, और App Store में देखा तो गायब था। सच में बहुत दुख हुआ
अच्छा होता अगर “स्क्रीन के बाएँ किनारे से दाएँ swipe करना back button दबाने जैसा है” वाले behavior को बंद किया जा सकता
स्क्रीन में फिट न होने वाले web page पर आम horizontal scroll करते समय बहुत बार गलती से back हो जाता है
iOS यह हिस्सा काफ़ी अच्छी तरह करता है
एक सामान्य iOS application में कई स्तरों वाली hierarchy tree जैसी fixed architecture होती है, और इसी सख़्त structure की वजह से navigation के विकल्प पहले से अनुमानित रहते हैं। यह structural navigation pattern user को भरोसा देता है कि वह कहाँ से आया है, hierarchy में कहाँ है, और वापस अपनी मूल जगह पर कैसे जा सकता है
वहीं Android में back gesture कभी पिछले page पर ले जाता है, तो कभी app को पूरी तरह बंद कर देता है। यह इतना inconsistent है कि Android 12 साल इस्तेमाल करने के बाद मैंने iOS पर switch कर लिया
हैरानी की बात है कि “अब और नहीं सह सकता” तय करने से पहले आपने पूरे 12 साल झेल लिए
जब मैंने पहली बार iPhone development शुरू किया था, यानी उस समय जब official SDK अभी-अभी आया था, तब Apple Human Interface Guidelines को लेकर बहुत सख़्त था, और अच्छा UI किन चीज़ों से बनता है तथा कौन से standard pattern अपनाने चाहिए, इस पर documentation भी बहुत अच्छी थी
लेकिन “flat” design में जाने के बाद लगता है कि वह सब पूरी तरह गायब हो गया। मेरा मानना है कि मुख्य वजह यह थी कि वे documents अब वैसे अर्थपूर्ण नहीं रहे थे
पहले बातें बहुत साफ़ होती थीं, जैसे “user interaction को स्पष्ट रूप से दिखाई देने वाला बनाओ”, लेकिन अब मामला ऐसा हो गया है: “यह clickable हो भी सकता है, सिर्फ text भी हो सकता है, या शायद इसे long-press करना पड़े”
नमस्ते! मुझे भी यह बात तब पता चली जब मैं यह लेख अपने सहकर्मी के साथ साझा कर रहा था। कोरियन वर्तनी के मानक के अनुसार
네비게이션नहीं, बल्कि내비게이션मानक रूप है। हा हा यह अंग्रेज़ी उच्चारण से आया शब्द है, इसलिए सच कहें तो किसे बिल्कुल सही कहा जाए, यह थोड़ा अस्पष्ट लग सकता है। लेकिन चूँकि यह ऐसी जगह है जहाँ बहुत से लोग देखते हैं, इसलिए सोचा कि अगर हो सके तो मानक रूप के अनुसार लिखा जाए तो अच्छा रहेगा, इसी वजह से हल्के-से एक टिप्पणी छोड़ रहा हूँ।यह लेख GPT-4 द्वारा तैयार किया गया सारांश है। लगता है कि GPT ज़्यादातर "नेविगेशन" का सही इस्तेमाल करता है, लेकिन कभी-कभी "नेविगेशन" भी मिलाकर लिख देता है। मैंने उसे ठीक कर दिया है haha