そんな進化を遂げたランチャーが、ユーザと OS の間のギャップをどのように減らそうとしたかを比較してみよう。
こういう場合、よく CUI と GUI という比較がされて、簡単には CUI → GUI というように発展を遂げたという位置付けがされる（あるいはそれを前提に CUI を擁護する）。あるいは、文字かアイコンかという比較も。
でも、ある時点での技術的な制限や OS の特性は捨象して、その適応戦略を位置付け直してみて、
という区別に重点をおいた方が、その形態比較が奇麗にできるんじゃないかと思った。
まず、「文字/綴り」による入力インタフェースは、コマンドラインという形に代表的だけど、入力位置を示すコマンドプロンプトだけがあって、あとはユーザが綴り（spell）を入力するのをコンピュータは待ち続ける（ここでは、識別最小単位としての文字とそれを入力するためのキーボードと言うのを前提）。
「綴り」も潜在的には数多くのコマンドの中から指定のものを選びだす行為だけど、原始的にはそのコマンドに対応する綴りをユーザが一字一句間違わずに入力することが必要となって来て、選ぶというのとは程遠い。つまりそれは spell のもう一つの意味、「呪文」という意味と相通じるもので、正確に唱えることでとある出来事を起こすことができる不思議な言葉なんだ（呪文を誤ると概ね変なことが起こるとこまでそっくり）。
この利点は、言葉というユーザ側が持つ習慣に依存することで（記憶の再生に頼ることで）、コンピュータの側からは入力を待てば良くて、また入力するために用意する空間も１行（コマンドライン line に引っかけて。あるいは、ある種の１レイヤー）だけで済むこと。また、その綴りの組合せによって多数のコマンドをそれぞれ対応することができるということ。
「文字/綴り」とは言ったけど、それは実体的な文字である必要はなくて、「ショートカットキー」「アクセラレータキー」やそれこそ呪文的な Emacs のコマンド、あるいはマウスの動作軌跡や Palm の Graffiti まで、ともかくある特定のストローク（一連の定型動作）をユーザの側が想起する、ということに強く依存するという点が一番の特徴だろう。
しかし、当然のようにその適応戦略は、コマンド起動とユーザのギャップを克服するのに対して、つねに綴りのインフレを問題としてかかえてしまう。
この２つの要求軸を満たそうとしても、増していくシステムの複雑さによって、区別するために単体のコマンド名の長さが長くなったり、そもそもコマンド数が増えるというインフレ圧力があって、当初の簡潔なコマンドライン入力も複雑さを押えることができなくなってくる。結果、ユーザが思い出せない（想起できない）という事態に陥ってしまう。
対して、「アイテム/オブジェクト」による選択インタフェースは、コンピュータの側からユーザに対して選択可能項目を積極的に提示することで、ユーザが行なう動作が「選択」という動作であるというというころに、「綴り」との大きな違いがある（それが絵であるか、文字であるかはここでは問わない）。
またこれは、ユーザ側に次の点で負担を軽減する、という目論みでもある。それは、「入力したいものを正確に想起/入力する必要がない」「画面上に表示された内容から正しく目的のものを選び出すことができるだけで良い」（再認識できれば良い）、という点。
いわば、画面という空間に行動/記憶が実体化されているわけだ。
しかし、こちらもまたあるインフレ圧力を抱えていて、それはユーザに提示しなければいけない選択項目数の増加である。
という要求軸を満たそうとしても、そのままではシステムの複雑さが増すに従って高まる項目数のインフレ圧力を処理できない。また、副次的に、その増加は、実際にユーザにとっての作業空間（デスクトップ）上を占めてしまう、という別の問題も起こってしまう。
こうして、２つの軸として始めたのは、どれぐらい/どのようにユーザ側の能力/記憶に依存するのか、コンピュータの側でサポートするのか、という対比軸でも読みとれることになる。