همهٔ مقاله‌ها

· Casimiro Ferreira· 7 دقیقه مطالعه

اگر همه یک اپلیکیشن عرضه می‌کنند، ما صدا عرضه می‌کنیم: تبدیل وب‌سایت‌ها به اپلیکیشن‌های صوتی

  • Voice
  • Accessibility
  • OpenVoiceOS
  • Web Automation
  • CLI
  • FOSS

جایی در پانزده سال گذشته، وب بی‌سروصدا تصمیم گرفت که هر سایت مهمی به یک اپلیکیشن موبایل هم نیاز دارد. نه به این دلیل که HTML از کار افتاده باشد — بلکه به این دلیل که یک اپلیکیشن یک سطح کنترل‌شده است: مجموعه‌ای گزیده از کنش‌ها، بدون هیچ عنصر واسطی که خودتان انتخابش نکرده باشید، رابطی ساخته‌شده برای یک شیوهٔ مشخص از تعامل.

ما فکر می‌کنیم همین حرکت در انتظار انجام‌شدن برای مجموعه‌ای متفاوت از کاربران و مجموعه‌ای متفاوت از رابط‌هاست. اگر همه سایت خود را به یک اپلیکیشن Android تبدیل می‌کنند، ما می‌توانیم سایت‌ها را به اپلیکیشن‌های صوتی تبدیل کنیم — و به اپلیکیشن‌های خط فرمان، و به جریان‌هایی بومی برای صفحه‌خوان‌ها. همان ایده، در جهت مخالف: بسته‌بندی یک سایت در سطحی ساخته‌شده برای شیوه‌ای که شما می‌خواهید با آن تعامل کنید، با این تفاوت که آن سطح، صدای شما و ترمینال شماست به‌جای یک صفحهٔ لمسی.

وب به‌سختی با گوش قابل استفاده است

برای کاربری بینا با یک ماوس، یک سایت مدرن قابل قبول است. برای کسی که با صدا مرور می‌کند، یا از طریق یک صفحه‌خوان، یا از یک ترمینال، بخش عمدهٔ وب یک محیط خصمانه است: دیوارهای اسکرول بی‌پایان، بنرهای کوکی، پاپ‌آپ‌ها، منوهایی که به یک نشانگر نیاز دارند، محتوایی مدفون زیر سه لایه از خرت‌وپرت تعاملی. اطلاعات آن تو هست. بیرون کشیدنش، بدون استفاده از دست، مصیبت‌بار است.

پاسخ همیشگی این است که «سایت‌ها باید دسترس‌پذیرتر باشند»، و باید باشند. اما ما قرار نیست کل وب را با خواهش و تمنا اصلاح کنیم. کاری که می‌توانیم بکنیم این است که سایت‌هایی را که اهمیت دارند برداریم و برای هرکدام یک رابط گفتاری و تمیز بسازیم — به همان شکلی که فروشگاه‌های اپلیکیشن برای لمس انجام دادند، اما برای صدا و خط فرمان، و به‌صورت باز.

دو لایه: یک API تمیز، سپس یک اسکیل صوتی

هر یک از این اپلیکیشن‌های صوتی دو قطعهٔ روی‌هم‌چیده است، و ما هر دو را از پیش می‌سازیم.

لایهٔ یک — یک کلاینت تایپ‌شده که یک سایت را به یک API تبدیل می‌کند. این دقیقاً همان کار ما در زمینهٔ اسکرپینگ و مهندسی معکوس API است: دست‌درازی به سایتی که هیچ رابط عمومی قابل‌استفاده‌ای ندارد و بازگرداندن اشیای ساختارمند و تایپ‌شده به‌جای HTML شکننده — فعل‌ها، نه اسکرپینگ:

from py_bandcamp import BandCamp

for release in BandCamp.search_albums("king gizzard"):
    artist = release.work.credits[0].entity.name if release.work.credits else ""
    print(release.work.title, artist, release.uri)

کار شناسایی و ابزار انتقال ضدبات که در زیر آن قرار دارد، این دسترسی را همزمان با تغییر سایت پابرجا نگه می‌دارد. آن کلاینت همین حالا هم به‌تنهایی مفید است: برای یک کاربر ترمینال، API همان نسخهٔ دسترس‌پذیر وب‌سایت است — کلاینت SoundCloud ما حتی nds را عرضه می‌کند، یک اپلیکیشن خط فرمان برای جست‌وجو و پخش موسیقی بدون هیچ مرورگری در میدان دید. وقتی یک سایت به یک API تبدیل شد، دیگر یک مصنوع بصری نیست و به چیزی تبدیل می‌شود که یک ماشین — یا یک پایپ‌لاین صوتی — می‌تواند آن را هدایت کند.

لایهٔ دو — یک افزونهٔ OVOS که آن API را حرف می‌زند. روی این کلاینت یک افزونهٔ OpenVoiceOS قرار می‌گیرد که نیت‌های گفتاری را به فراخوانی‌های API نگاشت می‌کند و نتایج را با صداهای TTS آفلاین ما روایت می‌کند. این عمداً یک اسکیل سفارشی برای هر سایت نیست — آن مسیر به ده‌ها اسکیل موردی می‌انجامد که هیچ‌کس نمی‌تواند نگهداری‌شان کند. برای هر چیزی که شکل رسانه‌ای دارد، این یک افزونهٔ فراهم‌کنندهٔ OCP است: یک مبدل کوچک که سطح جست‌وجو-و-پخش یک سایت را به کل چارچوب Open Common Play عرضه می‌کند، تا «جست‌وجو کن»، «پخش کن»، «بعدی» و «ادامه بده» از پیش به همان شکلی کار کنند که برای هر منبع دیگری کار می‌کنند. سایت به‌جای اختراع رابط خاص خودش، در یک رابط صوتی یکنواخت جا می‌افتد.

نتیجه: «کانال Groove Salad از SomaFM را پخش کن.» «در Bandcamp دنبال امبینت Creative-Commons بگرد.» وب‌سایت، تبدیل‌شده به چیزی که می‌توانید بدون نگاه‌کردن به آن استفاده کنید — و بدون یک دستور زبان جدید که برای هر سایت باید یاد بگیرید.

در عصر LLM ها، یک API تایپ‌شده یک رابط زبان‌طبیعی در انتظار وقوع است

دلیل دومی وجود دارد که چرا این شکل اکنون بیش از پنج سال پیش اهمیت دارد. یک کلاینت تمیز و تایپ‌شده دقیقاً همان چیزی است که یک مدل زبانی بزرگ برای تبدیل‌شدن به یک فرانت‌اند زبان‌طبیعی برای یک وب‌سایت به آن نیاز دارد.

به یک LLM یک مجموعهٔ مستندشده از توابع بدهید — search_albums، get_recommendations، stream_url — و او با خوشحالی «چیزی مثل Naxatras اما سنگین‌تر برایم پیدا کن» را به فراخوانی‌های درست ترجمه می‌کند، آن‌ها را به‌هم زنجیر می‌کند، و نتیجه را با صدا برمی‌گرداند. API ساختارمند بخش دشوار است؛ رابط گفت‌وگویی روی آن به‌طور فزاینده‌ای چیزی است که مدل به‌سادگی فراهم می‌کند، به‌شرط آنکه ابزارهایی که به دستش داده می‌شود خوش‌تایپ و صادق دربارهٔ آنچه بازمی‌گردانند باشند. HTML درهم‌ریخته چیزی به LLM نمی‌دهد که به آن چنگ بزند. یک کلاینت تایپ‌شده به او یک سطح کنترل می‌دهد.

پس کلاینت‌های وب‌سایت ما یک SKILL.md عرضه می‌کنند — توصیفی به زبان ساده از اینکه API چه کاری انجام می‌دهد، فعل‌هایش، انواع بازگشتی‌اش و نمونه فراخوانی‌هایش، نوشته‌شده برای اینکه یک عامل آن را بخواند. یک دستیار مبتنی بر LLM را به آن نشانه بروید و کلاینت به ابزاری تبدیل می‌شود که مدل می‌تواند بلافاصله از آن استفاده کند: بدون کد چسب، بدون یکپارچه‌سازی سفارشی، فقط «این کاری است که این سایت می‌تواند بکند، در قالب کلمات.» یک سند، یک اسکرپر را به چیزی تبدیل می‌کند که یک مدل زبانی می‌تواند از طرف شما آن را به کار بگیرد.

این همان دادهٔ ساختارمند است که همزمان به سه فرانت‌اند خدمت می‌کند: یک CLI برای کاربران ترمینال، یک افزونهٔ OCP/صوتی برای استفادهٔ بدون دست، و یک ابزار LLM برای کنترل با زبان طبیعی. API را یک بار بسازید؛ به سه شکل بپوشیدش.

چرا این بیش از همه برای کسانی اهمیت دارد که نمی‌توانند صفحه را ببینند

برای کاربران نابینا و کم‌بینا این یک ویژگی رفاهی نیست — این تفاوت میان دسترسی و طرد است. یک صفحه‌خوان تنها می‌تواند آنچه را بخواند که یک صفحه به‌شکل تمیز عرضه می‌کند، و بیشتر صفحه‌ها این کار را نمی‌کنند. یک اپلیکیشن صوتی اختصاصی صفحه را به‌کلی رد می‌کند: سراغ دادهٔ ساختارمند می‌رود و آن را حرف می‌زند، در جریانی که از همان نخستین خط کد برای گوش‌دادن طراحی شده است.

این همان اصلی است که پشت بازی‌های صدا-محور ما قرار دارد — ساخته‌شده برای گوش‌ها، نه چشم‌ها، با بازیکنان نابینا به‌عنوان مخاطب اصلی به‌جای یک فکر بعد از عمل. اپلیکیشن‌های صوتی برای وب‌سایت‌ها این اصل را از بازی‌ها به بقیهٔ وب گسترش می‌دهند.

یک سایت در هر نوبت — اما جهت‌گیری به‌سوی یک مرورگر صوتی است

اینجا بخش صادقانه‌اش است: هیچ میان‌بر جهانی‌ای وجود ندارد. نمی‌توانید «وب» را در یک حرکت صوتی‌سازی کنید، چون هر سایت درهم‌تنیدگی خاص خودش است. این کار باید برای هر سایت انجام شود — یک کلاینت، یک اسکیل، یک مجموعهٔ نیت‌های به‌دقت نگاشت‌شده در هر نوبت. این شبیه یک محدودیت به‌نظر می‌رسد، و در کوتاه‌مدت هم هست.

اما به جایی که این انباشت به آن اشاره می‌کند نگاه کنید. هر سایتی که ما بسته‌بندی می‌کنیم یک گوشهٔ دیگر از وب است که اکنون با صدا و با خط فرمان قابل دسترسی است. تعداد کافی از آن‌ها را کنار هم بگذارید — یک واژگان متادیتای مشترک، یک لایهٔ صوتی مشترک، یک مجموعهٔ سازگار از نیت‌های «جست‌وجو / باز کن / بخوان / پخش کن / بعدی» — و دیگر به یک انبوه از اسکیل‌های جدا نگاه نمی‌کنید. به آغاز یک مرورگر صوتی نگاه می‌کنید: راهی برای حرکت در وب با حرف‌زدن، جایی که سایت‌های منفرد صرفاً مقصدهایی هستند که از پیش می‌دانند چگونه پاسخ دهند.

شرط‌بندی عصر موبایل این بود که سایتی که ارزش استفاده دارد، ارزش یک اپلیکیشن را دارد. شرط‌بندی ما این است که سایتی که ارزش استفاده دارد، ارزش یک صدا را دارد. ما آن‌ها را یک‌به‌یک می‌سازیم، به‌صورت باز، و هر یک از آن‌ها وب را برای کسانی که وب بصری جاگذاشت، کمی قابل‌مرورتر می‌کند.

سایتی خاص را می‌خواهید که به یک اپلیکیشن صوتی یا خط فرمان تبدیل شود — برای دسترس‌پذیری، برای محصولتان، یا فقط به این دلیل که باید وجود داشته باشد؟ بیایید گفت‌وگو کنیم.