2 पॉइंट द्वारा GN⁺ 2024-08-21 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Toast notifications की मुख्य कमजोरी यह है कि उपयोगकर्ता का मौजूदा ध्यान-केंद्र और feedback की जगह अलग-अलग होती हैं, इसलिए अभी किए गए action के नतीजे को तुरंत जोड़कर समझना मुश्किल होता है
  • YouTube के save flow में दाईं ओर Save बटन, बीच में modal, और नीचे बाईं ओर toast के बीच नज़र घूमती है, जिससे interaction टूटता है और delay के दौरान कोई loading indicator भी नहीं होता
  • Checkbox बदलने के बाद, नवीनतम confirmation message देखने के लिए पिछले toast के गायब होने तक इंतज़ार करना पड़ता है, और toast का Undo बटन भी उस स्थिति में अनावश्यक है जहाँ checkbox को फिर से क्लिक किया जा सकता है
  • बेहतर तरीका यह है कि feedback को action की जगह के भीतर ही रखा जाए, जैसे playlist को बटन के नीचे दिखाना और checkbox बदलते समय loading indicator से progress दिखाना
  • Toast से भी बुरा है बिल्कुल कोई feedback न होना, इसलिए अगर बेहतर feedback को design या implement करने का समय नहीं है, तो toast का होना, न होने से बेहतर है

Toast की मूल समस्या

  • Toast notifications आम तौर पर उस जगह से काफ़ी दूर दिखाई देती हैं जहाँ उपयोगकर्ता का ध्यान गया होता है
  • अगर feedback उस बटन या edit किए जा रहे area से अलग जगह पर आए जिसे अभी दबाया गया है, तो उपयोगकर्ता के लिए action और result को जोड़कर समझना मुश्किल हो जाता है

YouTube save flow की समस्या

  • YouTube के उदाहरण में, उपयोगकर्ता स्क्रीन के दाईं ओर Save बटन क्लिक करता है, फिर स्क्रीन के बीच के modal और नीचे बाईं ओर के toast को बारी-बारी से देखता है
  • यह flow नज़र को कई जगह ले जाता है और feedback को तुरंत समझना भी कठिन बना देता है
    • Toast loading indicator के बिना delay से आता है
    • Modal के अंदर checkbox on या off करने पर, नया confirmation toast देखने के लिए पिछले toast के गायब होने तक कई सेकंड इंतज़ार करना पड़ता है
    • Toast का Undo बटन अनावश्यक है क्योंकि उपयोगकर्ता checkbox को दोबारा क्लिक कर सकता है

Toast के बिना समाधान

  • सिर्फ़ एक साधारण redesign से वही feedback toast के बिना दिया जा सकता है
    • Playlist को modal में नहीं, बल्कि बटन के ठीक नीचे दिखाया जाए
    • Checkbox on या off करते समय loading indicator दिखाया जाए
    • Loading indicator हटते ही स्वाभाविक रूप से पता चल जाता है कि action पूरा हो गया है
  • क्योंकि feedback उसी जगह रहता है जहाँ उपयोगकर्ता ने interaction किया था, इसलिए अलग toast की ज़रूरत नहीं पड़ती

Gmail और copy feedback के उदाहरण

  • Gmail में email archive करने पर confirmation toast दिखाई देता है
    • लेकिन email का list से गायब हो जाना ही archive के सफल होने का संकेत दे देता है
    • हालांकि undo function और keyboard shortcut इस्तेमाल करने की स्थिति में toast feedback उपयोगी हो सकता है
  • Clipboard में कुछ copy करने के बाद toast दिखने के उदाहरण भी हैं
    • उदाहरण में, बटन खुद ही पहले से confirmation state शामिल करता है, इसलिए toast पूरी तरह अनावश्यक है

फिर भी feedback ज़रूरी है

  • Toast से भी बुरा है बिल्कुल कोई feedback न होना
  • अगर बेहतर feedback mechanism को design या implement करने का समय नहीं है, तो toast, कुछ भी न होने से बेहतर है

Cakedesk में toast से बचने का तरीका

  • Cakedesk एक offline-first, subscription-free invoicing app है, और इसमें app के अंदर से email भेजे जा सकते हैं
  • Email के Send बटन को दबाने के बाद toast से feedback देने के बजाय, state change को उसी flow के भीतर जारी रहने के लिए design किया गया है
    • जो invoice नहीं भेजे गए हैं, उनकी list में Send बटन होता है
    • Email भेजते समय modal खुला रहता है, और submit बटन पर sending state दिखाई जाती है
    • Send सफल होने पर email animation के साथ स्क्रीन से बाहर जाता है, जो भेजे जाने के पूरा होने को दिखाता है
    • List का Send बटन Paid checkbox में बदल जाता है, जिससे यह पुष्टि होती है कि email भेज दिया गया है और उपयोगकर्ता अगले उपयोगी action की ओर बढ़ सकता है
  • उपयोगकर्ता context button दबाकर यह भी देख सकता है कि email भेजा गया है या नहीं

2 टिप्पणियां

 
wkang586 2024-08-26

तो मतलब बुरा toast ही बुरा होता है, सही??

 
GN⁺ 2024-08-21
Hacker News की राय
  • https://en.wikipedia.org/w/index.php?title=Toast_(computing)

  • मैं सहमत नहीं हूँ। ज़्यादातर तर्क ऐसे लगते हैं कि दोहराया गया UX खराब UX है
    ईमेल archive करने पर वह सूची से गायब हो जाता है, इसलिए वह पहले से ही success का संकेत देता है, या button पर check mark है इसलिए toast अनावश्यक है—ऐसे उदाहरणों से ज़ोरदार सहमति रखना मुश्किल है। एक ही बात को एक साथ अलग-अलग तरीकों से बताना bug नहीं, feature है, और यह पूरी मानव भाषा में भी मौजूद है। क्योंकि यह आदर्श न होने वाली स्थितियों में भी संदेश पहुँचाने में मदद करता है
    Toast हर action की स्थिति बताने का एक standard तरीका देता है और संभव हो तो undo भी उपलब्ध कराता है, इसलिए user pattern को जल्दी सीख सकता है। action के पास अतिरिक्त indicator भी valuable है, लेकिन कई बार toast के साथ होने पर उसका अर्थ साफ़ होता है। Toast हटाकर उसे कई specific indicators से बदल देने पर user को सिर्फ context के आधार पर “अब हो गया” के कई expressions सीखने पड़ेंगे। बुज़ुर्गों, दृष्टिबाधित लोगों और बच्चों के लिए यह खास तौर पर अच्छा नहीं हो सकता
    जब तक toast वास्तव में बाधा नहीं बनता, वह खराब UX नहीं बल्कि दोहराया हुआ UX है, और UX designers को redundancy हटाने के जुनून में नहीं पड़ना चाहिए

    • दुर्भाग्य से, वे दोनों एक ही बात नहीं बताते
      YouTube वाले उदाहरण में checkbox 100% optimistic update है, और toast notification का मतलब है कि backend को asynchronous तरीके से भेजा गया request सफल हुआ। email archive में भी यही है: message को optimistic तरीके से सूची से हटा दिया जाता है और toast बताता है कि वह सच में archive हो गया
      मैं तो चाहूँगा कि change commit fail होने पर ही toast मिले। आम तौर पर toast का अचानक चमकना मेरे किए जा रहे काम से ध्यान भटकाता है, और अगर वह action की जगह से screen पर दूर हो तो और भी ज़्यादा distract करता है
    • नहीं, toast खराब हैं। मेरे field of view या ध्यान की परिधि में आने वाला message, जैसे wide monitor के एक किनारे पर दिखने वाला message, actively confusion पैदा करता है। मैं यहाँ इस problem को handle कर रहा हूँ, और उधर कुछ flash होता है। पढ़ने के लिए focus shift करता हूँ, तब तक आधा गायब हो चुका होता है
      message को जहाँ user का ध्यान पहले से है वहीं रखना चाहिए। UI ने मेरी नज़र को वहाँ guide किया है, तो वहीं दिखाइए
    • मैं computer मुख्य रूप से magnification tool के साथ इस्तेमाल करता हूँ, text और mouse/finger cursor के आसपास का हिस्सा zoom करके। Toast और ज़्यादातर notifications उस जगह पर नहीं होते जहाँ मैं काम कर रहा होता हूँ, इसलिए वे लगभग छूट जाते हैं। मेरे इस्तेमाल के तरीके में जिस item से interaction हो रहा है, उसके पास का feedback ही value रखता है
    • कहा जाता है कि “communication में redundancy feature है, bug नहीं”, लेकिन अगर noise information बहुत ज़्यादा हो तो users उन्हें ignore करना सीख जाते हैं, और कभी-कभी जब सच में important information बीच में आ जाती है, तब problem होती है
      सीख यह है कि जो information strictly जरूरी नहीं है, उसे user को मत भेजिए
      और पढ़ने के लिए:
      https://en.wikipedia.org/wiki/Banner_blindness
      https://en.wikipedia.org/wiki/Alarm_fatigue
      https://en.wikipedia.org/wiki/Inattentional_blindness
      https://en.wikipedia.org/wiki/Habituation
    • मेरा मानना है कि सुझाए गए improvement का मतलब यह है। अगर आपको चिंता है कि जिस UI element से user interact कर रहा है वह current situation को पर्याप्त रूप से communicate नहीं कर रहा, तो user का ध्यान बाँटने वाला और जल्दी पढ़कर खुद connection बनाने की मांग करने वाला दूसरा element जोड़ने के बजाय उसी element को improve करना चाहिए। जिस element से user ने interaction किया, उसी के context में failure बताने से connection स्पष्ट होता है
      सबसे खराब case में, context के बिना user तक बात पहुँचाने के last resort के रूप में toast समझ में आता है। उदाहरण के लिए, user ने playlist का check हटाया और save होते समय playlist list बंद कर दी, लेकिन save fail हो गया; तब action का context गायब हो चुका है, इसलिए screen पर कहीं arbitrary जगह information दिखाने वाला toast भी समझ में आता है
      फिर भी अगर आप चाहते हैं कि user error को ठीक से समझे, तो toast शायद best नहीं है। YouTube जैसी ad-based app, जहाँ user ही product है, में user का ऐसे errors miss करना शायद उन्हें खास परेशान न करे या उल्टा वे यही चाहें, लेकिन work app में आप यह risk नहीं लेना चाहेंगे कि user toast miss कर दे या उसे किसी दूसरे error से confuse कर दे। आम तौर पर user के लिए बेहतर होता है कि संबंधित element को फिर से खोलकर error को context में दिखाया जाए। playlist list खोली जा सकती है और एक animation देकर ध्यान दिलाया जा सकता है कि change save नहीं हुआ। इसे systematically implement करना मुश्किल idealism हो सकता है, लेकिन ideally हमेशा context में error दिखना चाहिए
  • सबसे खराब बात यह है कि toast बहुत जल्दी गायब हो जाता है, और उन कामों में भी बेवजह ध्यान खींचता है जिनमें सफलता सामान्यतः expected होती है। दोनों मिल जाएँ तो खास तौर पर चिढ़ होती है। ध्यान बेवजह टूटता है, लेकिन वह इतनी जल्दी गायब हो जाता है कि यह पता ही नहीं चलता कि उसमें सच में कोई महत्वपूर्ण बात थी या नहीं। उलटा एक variant यह भी है कि वह बहुत देर तक रहता है और UI के उस हिस्से को ढक देता है जिसे आप तुरंत देखकर इस्तेमाल करना चाहते थे
    पारंपरिक desktop तरीका बेहतर है। error message को छूटने न देने के लिए modal में दिखाएँ, और success message को बिना time limit के हमेशा दिखने वाले status bar में non-intrusive सामान्य text के रूप में दिखाएँ। अगर error modal नहीं है, तो user मान सकता है कि काम सफल रहा; और अगर confirmation चाहिए, तो बिना time pressure के status bar में देख सकता है। उसमें अतिरिक्त जानकारी भी रखी जा सकती है
    कुछ apps status bar message history को popup के रूप में भी दिखाते हैं। इस तरीके में status bar command-line terminal की आखिरी output line जैसा होता है, और पुराना output भी वापस लाया जा सकता है

    • साथ ही, कुछ toast user को ज़रूरी महत्वपूर्ण जानकारी दिखाते हैं लेकिन बहुत जल्दी गायब हो जाते हैं, और toast size limit की वजह से content भी अधूरा होता है
      छूटी हुई बात देखने के लिए मुझे अक्सर notifications में जाना पड़ता है। क्योंकि वह महत्वपूर्ण लग रहा था, लेकिन पूरा पढ़ने का समय कम था। वहाँ जब truncated message जैसा दिखने वाले item पर tap करता हूँ, तो उम्मीद होती है कि यह पूरे context में ले जाएगा; लेकिन असल में notification गायब हो जाता है और सिर्फ app खुलता है, उस issue पर deep link नहीं होता। फिर app के standard UI के अंदर उस समस्या को ढूँढते फिरना पड़ता है, जो वहाँ दिख भी सकती है और नहीं भी
      यह मेरे साथ अनगिनत बार हुआ है, और हर बार ऐसे system को design करने वाले व्यक्ति पर गुस्सा आता है
    • toast ऐसा एहसास कराता है जैसे कहीं कोई event log होगा जिसमें बाद में देखा जा सके कि क्या हुआ था। असलियत में accessible event log नहीं होता, और toast message timeout होकर गायब हुआ तो हमेशा के लिए चला गया
    • एक thought experiment के तौर पर, toast स्क्रीन पर कितनी देर रहना चाहिए? user को पढ़ने का समय मिलना चाहिए, लेकिन user कब नज़र उठाएगा यह नहीं पता, पढ़ने की speed भी नहीं पता, इसलिए कोई सुरक्षित upper limit नहीं है
      आज मेरे बेटे के साथ मुझे यही समस्या हुई। वह पढ़ने की speed practice कर रहा है, इसलिए हम एक नया app साथ में इस्तेमाल कर रहे थे, लेकिन toast लगातार आते रहे, जिससे उसके लिए follow करना मुश्किल हुआ और वह distracted हो गया। अंत में मुझे उसे ज़ोर से पढ़कर सुनाना पड़ा। अगर message ज़्यादा देर रहने वाला होता, तो वह अतिरिक्त मदद के बिना भी सफल हो सकता था
    • बेहतर समाधान यह है कि success को assume किया जाए, और ऐसे messages केवल error आने पर दिखाए जाएँ
    • toast की सबसे खराब implementation वह है जो सच में UI elements को ढक देती है, ताकि toast गायब होने तक वे न दिखें और न click किए जा सकें
  • YouTube में इससे बेहतर उदाहरण है
    https://www.youtube.com/feed/history पर जाएँ, दाईं ओर “Comments” दबाएँ और फिर कोई comment delete करके देखें; deletion pending बताने वाला एक toast आता है, और 1–2 सेकंड बाद deleted बताने वाला एक और toast आता है
    अगर आप कई comments को तेजी से लगातार delete करें, तो पहले कई deletion pending toast आते हैं, और 1–2 सेकंड की delay के बाद हर confirmation toast क्रम से आता है। असली deletion भी sequentially होता है, इसलिए सारे confirmation toast का इंतज़ार करना पड़ता है। अगर आपने 10 comments को 2–3 सेकंड में click कर दिया हो, तब भी confirmation में 10 सेकंड से ज़्यादा लगते हैं
    live comments में भी यही है:
    https://myactivity.google.com/page?page=youtube_live_chat&co...

  • “toast का Undo button unnecessary है क्योंकि user checkbox को फिर से click कर सकता है” वाली बात से मैं आम तौर पर सहमत नहीं हूँ। जब गलती से कहीं click हो गया हो, लेकिन ठीक-ठीक कहाँ हुआ यह न पता हो, और app को इतना अच्छी तरह न जानते हों कि message देखकर आसानी से वापस कर सकें, तब undo बहुत अच्छा होता है

    • इस specific example में undo button पहले से है। वह खुद checkbox है। समस्या यह है कि वह checkbox जिस exact state को दिखाना चाहिए, उससे match नहीं करता। check करने पर कुछ सेकंड तक check तो रहता है लेकिन video अभी saved नहीं होता; uncheck करने पर toast आने तक अभी unsaved नहीं होता। बार-बार check/uncheck करें तो final state क्या है, पता नहीं चलता
    • ऐसा मैंने कुछ systems में झेला है। यह तो पता होता है कि अभी गलत item बदल दिया, लेकिन कौन-सा item था यह नहीं पता और कोई clue भी नहीं। खास तौर पर तब समस्या होती है जब संभव है कि कुछ भी न बदला हो, लेकिन यकीन न हो
      एक extreme example लें: मान लीजिए आपकी पीठ मुड़ी हुई थी और एक ball shelf से लुढ़ककर keyboard से टकरा गई। क्या कुछ बदला? क्या बदला? उसे कैसे ठीक करें?
  • Toast का मतलब सिर्फ एक ही स्थिति में बनता है: जब notification उपयोगकर्ता की मौजूदा action से संबंधित न हो। यह कुछ वैसा ही है जैसे अब गायब हो चुका Growl OS-टाइप notifications देता था
    उपयोगकर्ता की action पर feedback उसी action के context में मिलना चाहिए। अगर action asynchronous है, तो यह साफ होना चाहिए, और feedback तुरंत दिखाना चाहिए कि संबंधित काम processing queue में चला गया है। इस स्थिति में feedback में cancel करने और queue तक पहुंचने का विकल्प, और बेहतर हो तो progress देखने का विकल्प भी देना चाहिए

    • मैं एक और scenario जोड़ना चाहूंगा। अक्सर ऐसा होता है कि feedback देने वाला UI element पहले ही हट चुका होता है, लेकिन फिर भी feedback दिखाना चाहते हैं
      अगर आपने board से कोई task हटा दिया, तो उसी task पर undo करने का तरीका नहीं दिखा सकते। Keyboard shortcut से undo किया जा सकता है, लेकिन उपयोगकर्ता को यह visually कैसे पता चलेगा?
      Task list में सिर्फ tasks ही होने चाहिए, इसलिए task की जगह कोई note नहीं रखेंगे। केवल message दिखाने के लिए कोई derived task जैसा भी नहीं बनाएंगे। ऐसा करने का मतलब task component में बिना function वाला intent ठूंसना होगा। उपयोगकर्ता को बिल्कुल न बताना भी मुझे पसंद नहीं। Task हट गया है, यह तो स्पष्ट है, लेकिन एक click से हुई इस असहज action को वापस कैसे किया जाए, यह स्पष्ट नहीं है। और हर बार task delete करने से पहले परेशान करने वाला confirmation भी नहीं मांगेंगे। यह task list की core functionality है, इसलिए इसे तुरंत होना चाहिए और तुरंत undo भी किया जा सकना चाहिए
      ऐसे छोटे-छोटे special cases बहुत होंगे। Toast का आविष्कार किसी वजह से हुआ था। लोगों ने इसे cute तरीके से misuse किया, इसका मतलब यह नहीं कि यह कुछ खास scenarios में सचमुच उपयोगी नहीं है
    • Modal tasks में, जहां उपयोगकर्ता task शुरू करने के बाद 99% मामलों में उसे background में भेजकर कुछ और करना चाहता है, ऐसा feedback कहां देना चाहिए?
    • ऐसे उदाहरण भी हैं जो मौजूदा user action से संबंधित हैं, लेकिन अभी दिखाई दे रही screen area के बाहर हैं। जैसे USB memory लगाना या कोई दूसरा hardware-related function चलाना
      ऐसी actions का screen पर कोई context नहीं होता, और अक्सर आगे की action की जरूरत होती है। भले ही आगे कोई action न हो, उपयोगकर्ता की action detect हुई है इसकी confirmation देना साफ तौर पर उपयोगी है
    • यह कहने का मतलब नहीं कि OS-टाइप notifications का आविष्कार Growl ने किया था। Growl 2004 में आया था, और Windows XP में 2001 में notifications थे। अगर Clippy के messages को notifications माना जाए, तो कम से कम Microsoft Bob (1995) तक पीछे जाया जा सकता है
  • जिन लोगों को confusion हुआ, उनके लिए: यह लेख toasted bread [1] के बारे में नहीं, बल्कि एक तरह के UI widget [2] के बारे में है
    [1] https://en.wikipedia.org/wiki/Toast_(food)
    [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

    • यह ironic है कि खराब communication paradigm पर लेख खुद यहां यह नहीं समझाता कि toast का मतलब क्या है
      Page का सबसे महत्वपूर्ण शब्द यही है, और साफ है कि technical readers में भी कुछ लोग इस jargon को नहीं समझते
      हालांकि baking और breakfast recipes में रुचि रखने वाले readers की वजह से engagement शायद और बढ़ गया हो
  • “Toast में Undo button unnecessary है क्योंकि user checkbox को फिर से click कर सकता है” वाली बात पर कहूं, तो मैं इस feature की खास तौर पर कद्र करता हूं। अनगिनत बार ऐसा हुआ है कि मुझे लगा मैंने email archive किया है, लेकिन toast ने बताया कि मैंने spam report button दबा दिया था। वरना मुझे बिल्कुल पता नहीं चलता
    Original लेख ने toast की एक और बुनियादी समस्या छोड़ दी है: web actions asynchronous होती हैं। पता नहीं चलता कि action successful हुई, fail हुई, या server तक register भी हुई या नहीं। Toast server state के बारे में asynchronous update देता है
    हां, मैं मानता हूं कि कुछ toasts annoying होते हैं, और कभी-कभी important UI content को ढकते हैं और उन्हें close भी नहीं किया जा सकता

    • Original लेख ने toast का मूल point पूरी तरह miss कर दिया। कुछ user actions 1) गलती से हो सकती हैं और 2) अक्सर बार-बार की जाती हैं, इसलिए confirmation box के साथ अच्छी तरह fit नहीं बैठतीं
      इसलिए अगर गलती से कुछ दब गया और email अचानक inbox से गायब हो गया, तो undo button वाला toast चाहिए। अगर आप बस बैठे हों और आपका शरीर button पर टिक जाए और अचानक toast दिखे, तो आप खुश होंगे कि वह मौजूद था। संभव हो तो उसमें की गई action का description और undo button होना चाहिए
      Gimp में Tab दबाने पर पूरा UI छिप जाता है, और shortcut न पता हो तो वापस लाने का तरीका नहीं होता। Image को focus से देखना चाहने वाले artists के लिए यह अच्छा feature है। लेकिन जब गलती से दबाने पर मुझे “gimp how to fix interface disappeared” search करना पड़ा, तब undo button वाले toast की कितनी जरूरत महसूस हुई, बता नहीं सकता। Computer से कम परिचित व्यक्ति कैसे react करता, इसकी कल्पना भी नहीं कर सकता
  • Toast खराब UX हो सकता है। आमतौर पर तब, जब वही अकेला feedback हो, लेकिन दूसरे elements के साथ इस्तेमाल किया जाए तो शानदार है
    Page redirect के साथ दिखने वाला confirmation toast, submission successful होने का अच्छा अतिरिक्त संकेत है
    Standard form validation indicators के साथ दिखने वाला warning या error toast, user को यह बताने का बेहतरीन secondary indicator बनता है कि उसे कुछ बदलना है
    Unspecified errors को catch-all की तरह handle करने के लिए implement करने पर user को error page पर भेजे बिना उसकी page state बचाई जा सकती है
    इसे अकेला tool नहीं, बल्कि toolbox का एक tool मानकर इस्तेमाल किया जाए तो यह अच्छा विकल्प है

  • टोस्ट से भी बुरी चीज़ होती है: छिपा हुआ स्लाइड पैनल। मूल रूप से यह छिपा हुआ टोस्ट ही है; किसी action के लिए ज़रूरी होते हुए भी बिल्कुल intuitive नहीं, और न इसे ढूंढा जा सकता है न discover किया जा सकता है। सबसे खराब अनुभव तब था जब मैं किसी और के फोन पर Waze इस्तेमाल कर रहा था। कुछ करना था, लेकिन याद नहीं कि क्या; मैं बस स्क्रीन को घूरता रहा और अंदाज़ा लगाता रहा कि क्या करना चाहिए। आखिरकार उस व्यक्ति ने फोन लिया और दाईं तरफ से छिपा हुआ पैनल slide करके दिखाया
    समझ आता है कि इससे जगह बचती है, लेकिन यह सच में बेतुका है। कोई UX विशेषज्ञ कैसे उम्मीद कर सकता है कि user यह guess कर लेगा? क्या आजकल UI ऐसे लोगों को मानकर बनाए जाते हैं जो बच्चे की तरह इधर-उधर टैप करके चीज़ें discover करते हैं?

    • अगर user को पता हो, और एक main sidebar तथा दो sidebars से ज़्यादा न हों, तो मुझे लगता है कि left/right slide से sidebar खोलने वाला UX ठीक है
      Discord mobile app पहले left और right दोनों sidebars के लिए यह तरीका इस्तेमाल करता था, लेकिन किसी समय किसी ने यह शानदार विचार दिया कि “swipe to reply” gesture app navigation से ज़्यादा महत्वपूर्ण है, और अब right sidebar देखने के लिए एक छोटा और अस्पष्ट button दबाना पड़ता है
    • मुझे याद है कि Snapchat install करते ही तुरंत समझ आ गया था कि यह कितना भयानक है। अलग-अलग corners में अलग-अलग functions थे। ऐसी चीज़ों को गैरकानूनी होना चाहिए
    • पूरी तरह सहमत। iOS तो जाहिर तौर पर ऐसी चीज़ों से भरा हुआ है, और पर्याप्त screen space वाले tablets पर भी ऐसा ही है
    • ज़्यादातर “toasts” के लिए, अब मुझे शब्द तो पता है, लेकिन मुझे वे redundant और बेकार लगते हैं। आमतौर पर मैं उन्हें पूरी तरह miss कर देता हूं। सामान्य तौर पर मुझे वे हानिकारक नहीं लगते, लेकिन important information देने के लिए उनका इस्तेमाल नहीं होना चाहिए
      “छिपे हुए panels” के बारे में मैं हमेशा सोचता था कि यह bug है, लेकिन शायद किसी ने इसे अच्छा idea माना होगा
      मैं App Store में apps manage करने के लिए Apple Connect app अक्सर इस्तेमाल करता हूं। जब मैं iPad Mini को portrait mode में इस्तेमाल करता हूं और अपनी apps में से किसी एक को चुनता हूं, तो back button अक्सर गायब हो जाता है। तब मैं न कोई दूसरा account चुन सकता हूं, न current account के अंदर कोई दूसरी app
      जब तक मैं iPad को physically landscape में नहीं घुमा देता। फिर left side में navigator दिखाई देता है और मैं दूसरी app चुन सकता हूं या account बदल सकता हूं
      सच कहूं तो Apple App Store backend के पूरे UX से मैं काफी निराश हूं। frontend भी मुझे बहुत पसंद नहीं, लेकिन backend वह जगह है जिसे मैं लगातार इस्तेमाल करता हूं। platform के बाकी user experience पर वे जितना ध्यान देते हैं, उसे देखते हुए यह काफी चौंकाने वाला है