صوتی وب، خط مشی پخش خودکار و بازی ها

Tom Greenaway
Hongchan Choi

در سپتامبر 2017، تغییراتی را در نحوه مدیریت صدا با خط‌مشی رفتار پخش خودکار در Chrome اعلام کردیم. این تغییر خط‌مشی با Chrome 66 Stable در می ۲۰۱۸ منتشر شد.

پس از بازخورد انجمن توسعه صوتی وب، انتشار بخش صوتی وب از خط‌مشی پخش خودکار را به تاخیر انداختیم تا به توسعه‌دهندگان زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم. ما همچنین تغییراتی را در اجرای خط‌مشی Web Audio ایجاد کرده‌ایم که باعث کاهش تعداد وب‌سایت‌هایی می‌شود که نیاز به تنظیم کد خود دارند - به ویژه بازی‌های وب - و بنابراین تجربه بهتری را برای کاربران خود فراهم می‌کنند.

این تغییر خط مشی اکنون قرار است در دسامبر 2018 با Chrome 71 عرضه شود.

تغییر سیاست دقیقا چه کاری انجام می دهد؟

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

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

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

ما این کار را با نمایه‌ای انجام می‌دهیم که به‌صورت محلی در نمایه Chrome در یک دستگاه ذخیره می‌شود - بین دستگاه‌ها همگام‌سازی نمی‌شود و فقط به عنوان بخشی از آمار کاربران ناشناس به اشتراک گذاشته می‌شود. ما این فهرست را نمایه تعامل رسانه (MEI) می نامیم و می توانید آن را از طریق chrome://media-engagement مشاهده کنید.

MEI تعداد بازدید از یک سایت شامل پخش صوتی بیش از 7 ثانیه را پیگیری می کند. بر اساس MEI کاربر، ما معتقدیم که می‌توانیم بفهمیم که آیا کاربر از یک وب‌سایت خاص انتظار صدا دارد یا نه - و هدف کاربر را در آینده پیش‌بینی کنیم.

اگر کاربر اغلب به دامنه وب سایت اجازه پخش صدا را برای بیش از 7 ثانیه می دهد، در آینده فرض می کنیم که کاربر انتظار دارد این وب سایت حق پخش خودکار صدا را داشته باشد. بنابراین، ما به آن وب سایت حق پخش خودکار صدا را بدون نیاز به تعامل کاربر با یک برگه از آن دامنه می دهیم.

با این حال، این حق به طور نامحدود تضمین نمی شود. اگر رفتار کاربر تغییر کند - به عنوان مثال توقف پخش صدا یا بستن برگه در آستانه 7 ثانیه در طول چندین بازدید - آنگاه حق وب سایت برای پخش خودکار را حذف می کنیم.

هر دو استفاده از عناصر HTML رسانه (ویدئو و صدا) و صدای وب (اشیاء AudioContext نمونه سازی شده جاوا اسکریپ) به MEI کمک خواهند کرد. در آماده‌سازی برای عرضه این خط‌مشی، رفتار کاربر در رابطه با Web Audio از Chrome 70 به بعد شروع به کمک به MEI خواهد کرد. این تضمین می‌کند که ما می‌توانیم قصد مورد نظر کاربر را در مورد پخش خودکار و وب‌سایت‌هایی که معمولاً بازدید می‌کنند، پیش‌بینی کنیم.

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

به تعویق انداختن تغییر برای حمایت از جامعه

هنگامی که این تغییر در کانال Chrome Stable ظاهر شد، جامعه توسعه دهندگان Web Audio - به ویژه توسعه‌دهنده بازی‌های وب و بخش‌های توسعه‌دهنده WebRTC از این انجمن، متوجه شدند.

بازخورد جامعه این بود که بسیاری از بازی‌های وب و تجربیات صوتی وب تحت تأثیر منفی این تغییر قرار می‌گیرند – به‌ویژه، بسیاری از سایت‌هایی که به‌روزرسانی نشده‌اند دیگر صدا را برای کاربران پخش نمی‌کنند. در نتیجه، تیم ما به این نتیجه رسید که ارزش این را دارد که این تغییر را به تأخیر بیندازیم تا به توسعه دهندگان صوتی وب زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم.

علاوه بر این، ما این زمان را به این موارد اختصاص دادیم:

  • به طور جدی در نظر بگیرید که آیا این تغییر سیاست بهترین اقدام بود یا خیر.
  • روش‌هایی را که می‌توانیم به کاهش تعداد وب‌سایت‌های صوتی که تحت تأثیر قرار می‌گیرند کمک کنیم، کاوش کنید.

در مورد اولی، ما در نهایت تصمیم گرفتیم که تغییر خط مشی در واقع برای بهبود تجربه کاربر برای اکثر کاربران ما ضروری است. جزئیات بیشتر در مورد مشکلی که تغییر خط مشی حل می کند را می توانید در بخش بعدی این مقاله بخوانید.

برای دومی، ما تنظیماتی را در پیاده سازی خود برای Web Audio انجام داده ایم که تعداد وب سایت هایی را که در ابتدا تحت تأثیر قرار گرفته اند کاهش می دهد. از میان سایت‌هایی که می‌دانستیم با این تغییر شکسته شده‌اند - که بسیاری از آنها به عنوان نمونه توسط جامعه توسعه بازی‌های وب ارائه شده‌اند - این تنظیم به این معنی است که بیش از 80٪ از آنها به طور خودکار کار می‌کنند. تجزیه و تحلیل و آزمایش ما از این سایت های نمونه را می توان در اینجا مشاهده کرد . این تنظیم جدید با جزئیات بیشتر در زیر توضیح داده شده است.

ما همچنین تغییری برای پشتیبانی از برنامه های WebRTC ایجاد کردیم. در حالی که یک جلسه ضبط فعال وجود دارد، پخش خودکار مجاز خواهد بود.

این تغییر رفتار با هدف حل چه مشکلی است؟

مرورگرها از لحاظ تاریخی در کمک به کاربر در مدیریت صدا ضعیف بوده اند. وقتی کاربران یک صفحه وب را باز می کنند و صدایی را دریافت می کنند که انتظار یا نمی خواستند، تجربه کاربری ضعیفی دارند. این تجربه کاربری ضعیف مشکلی است که ما سعی در حل آن داریم. نویز ناخواسته دلیل اصلی این است که کاربران نمی خواهند مرورگر آنها محتوا را به صورت خودکار پخش کند.

با این حال، گاهی اوقات کاربران می خواهند محتوا به صورت خودکار پخش شود و تعداد قابل توجهی از پخش خودکار مسدود شده در Chrome متعاقبا توسط کاربر پخش می شود.

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

یکی از پیشنهادات ارائه شده توسط انجمن، بی صدا کردن صدای یک برگه به ​​جای توقف پخش خودکار بوده است. با این حال، ما معتقدیم که بهتر است تجربه پخش خودکار را متوقف کنیم تا وب‌سایت از مسدود شدن پخش خودکار آگاه شود و به توسعه‌دهنده وب‌سایت اجازه دهد تا به این موضوع واکنش نشان دهد. برای مثال، در حالی که برخی از توسعه دهندگان ممکن است بخواهند به سادگی صدا را بی صدا کنند، سایر توسعه دهندگان ممکن است ترجیح دهند محتوای صوتی آنها تا زمانی که کاربر فعالانه با محتوا درگیر شود، متوقف شود - در غیر این صورت کاربر ممکن است بخشی از تجربه صوتی را از دست بدهد.

تنظیمات جدید برای کمک به توسعه دهندگان بازی های وب

رایج ترین روشی که توسعه دهندگان از Web Audio API استفاده می کنند، ایجاد دو نوع شی برای پخش صدا است:

توسعه دهندگان صوتی وب یک AudioContext برای پخش صدا ایجاد می کنند. برای از سرگیری صدای خود پس از اینکه خط مشی پخش خودکار به طور خودکار AudioContext خود را به حالت تعلیق درآورد، آنها باید تابع resume() را در این شیء پس از تعامل کاربر با برگه فراخوانی کنند:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

اینترفیس‌های زیادی وجود دارند که از AudioNode به ارث می‌برند، یکی از آنها رابط AudioScheduledSourceNode است. AudioNode هایی که رابط AudioScheduledSourceNode را پیاده سازی می کنند معمولاً به عنوان گره های منبع (مانند AudioBufferSourceNode، ConstantSourceNode و OscillatorNode) نامیده می شوند. گره های منبع یک متد start() را پیاده سازی می کنند.

گره‌های منبع معمولاً قطعه‌های صوتی جداگانه‌ای را نشان می‌دهند که بازی‌ها پخش می‌کنند، برای مثال: صدایی که هنگام جمع‌آوری سکه توسط بازیکن پخش می‌شود یا موسیقی پس‌زمینه‌ای که در مرحله فعلی پخش می‌شود. توسعه دهندگان بازی به احتمال زیاد هر زمان که هر یک از این صداها برای بازی ضروری باشد، تابع start() را روی گره های منبع فراخوانی می کنند.

هنگامی که این الگوی رایج در بازی های وب را شناختیم، تصمیم گرفتیم پیاده سازی خود را به موارد زیر تنظیم کنیم:

یک AudioContext به صورت خودکار از سر گرفته می شود که دو شرط برآورده شود:

  • کاربر با یک صفحه تعامل داشته است.
  • متد start() یک گره منبع فراخوانی می شود.

با توجه به این تغییر، اکثر بازی های وب اکنون زمانی که کاربر بازی را شروع می کند، صدای خود را از سر می گیرند.

حرکت وب به جلو

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

با این وجود، ما می دانیم که اعمال اصلاحات برای وب سایت ها به دلایل مختلف همیشه در کوتاه مدت امکان پذیر نیست:

  • توسعه دهندگان وب ممکن است بر روی یک پروژه جدید متمرکز شوند و نگهداری از یک وب سایت قدیمی بلافاصله امکان پذیر نیست.
  • پورتال های بازی های وب ممکن است کنترلی بر اجرای بازی ها در کاتالوگ خود نداشته باشند و به روز رسانی صدها - اگر نه هزاران - بازی ممکن است برای ناشران وقت گیر و گران باشد.
  • برخی از وب‌سایت‌ها ممکن است به سادگی بسیار قدیمی باشند و – به دلایلی – دیگر نگهداری نمی‌شوند اما همچنان برای اهداف تاریخی میزبانی می‌شوند.

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

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

لازم به ذکر است که این قطعه کد به از سرگیری AudioContext هایی که در یک iframe نمونه سازی شده اند کمکی نمی کند، مگر اینکه این قطعه کد در محدوده محتوای خود iframe گنجانده شود.

ارائه خدمات بهتر به کاربران

برای همراهی با تغییر خط‌مشی، ما همچنین مکانیزمی را برای کاربران معرفی می‌کنیم تا خط‌مشی پخش خودکار را غیرفعال کنند تا مواردی را پوشش دهد که یادگیری خودکار طبق انتظار کار نمی‌کند یا برای وب‌سایت‌هایی که با این تغییر غیرقابل استفاده می‌شوند. این تغییر با خط‌مشی جدید در Chrome 71 اعمال می‌شود و می‌توانید آن را در تنظیمات صدا پیدا کنید. سایت هایی که کاربر می خواهد به پخش خودکار اجازه دهد می توانند به لیست مجاز اضافه شوند.

چگونه MEI برای کاربران جدید ساخته شده است؟

همانطور که قبلا ذکر شد، ما MEI را به طور خودکار در طول زمان بر اساس رفتار کاربر ایجاد می کنیم تا هدف مورد نظر آنها را در رابطه با یک وب سایت خاص با محتوای پخش خودکار پیش بینی کنیم. هر وب سایت در این شاخص امتیازی بین صفر تا یک دارد. نمرات بالاتر نشان می دهد که کاربر انتظار دارد محتوا از آن وب سایت پخش شود.

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

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

یافتن تعادل

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

ما همیشه کاربران خود را در اولویت قرار می دهیم، اما همچنین نمی خواهیم جامعه توسعه وب را ناامید کنیم. گاهی اوقات مرورگر بودن به این معنی است که این دو هدف باید به دقت متعادل شوند. ما معتقدیم که با تنظیماتی که در اجرای این خط‌مشی انجام داده‌ایم و زمان اضافی که برای توسعه‌دهندگان صوتی وب برای به‌روزرسانی کدشان در نظر گرفته‌ایم، با Chrome 71 به این تعادل دست خواهیم یافت.

بازخورد

،

Tom Greenaway
Hongchan Choi

در سپتامبر 2017، تغییراتی را در نحوه مدیریت صدا با خط‌مشی رفتار پخش خودکار در Chrome اعلام کردیم. این تغییر خط‌مشی با Chrome 66 Stable در می ۲۰۱۸ منتشر شد.

پس از بازخورد انجمن توسعه صوتی وب، انتشار بخش صوتی وب از خط‌مشی پخش خودکار را به تاخیر انداختیم تا به توسعه‌دهندگان زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم. ما همچنین تغییراتی را در اجرای خط‌مشی Web Audio ایجاد کرده‌ایم که باعث کاهش تعداد وب‌سایت‌هایی می‌شود که نیاز به تنظیم کد خود دارند - به ویژه بازی‌های وب - و بنابراین تجربه بهتری را برای کاربران خود فراهم می‌کنند.

این تغییر خط مشی اکنون قرار است در دسامبر 2018 با Chrome 71 عرضه شود.

تغییر سیاست دقیقا چه کاری انجام می دهد؟

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

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

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

ما این کار را با نمایه‌ای انجام می‌دهیم که به‌صورت محلی در نمایه Chrome در یک دستگاه ذخیره می‌شود - بین دستگاه‌ها همگام‌سازی نمی‌شود و فقط به عنوان بخشی از آمار کاربران ناشناس به اشتراک گذاشته می‌شود. ما این فهرست را نمایه تعامل رسانه (MEI) می نامیم و می توانید آن را از طریق chrome://media-engagement مشاهده کنید.

MEI تعداد بازدید از یک سایت شامل پخش صوتی بیش از 7 ثانیه را پیگیری می کند. بر اساس MEI کاربر، ما معتقدیم که می‌توانیم بفهمیم که آیا کاربر از یک وب‌سایت خاص انتظار صدا دارد یا نه - و هدف کاربر را در آینده پیش‌بینی کنیم.

اگر کاربر اغلب به دامنه وب سایت اجازه پخش صدا را برای بیش از 7 ثانیه می دهد، در آینده فرض می کنیم که کاربر انتظار دارد این وب سایت حق پخش خودکار صدا را داشته باشد. بنابراین، ما به آن وب سایت حق پخش خودکار صدا را بدون نیاز به تعامل کاربر با یک برگه از آن دامنه می دهیم.

با این حال، این حق به طور نامحدود تضمین نمی شود. اگر رفتار کاربر تغییر کند - به عنوان مثال توقف پخش صدا یا بستن برگه در آستانه 7 ثانیه در طول چندین بازدید - آنگاه حق وب سایت برای پخش خودکار را حذف می کنیم.

هر دو استفاده از عناصر HTML رسانه (ویدئو و صدا) و صدای وب (اشیاء AudioContext نمونه سازی شده جاوا اسکریپ) به MEI کمک خواهند کرد. در آماده‌سازی برای عرضه این خط‌مشی، رفتار کاربر در رابطه با Web Audio از Chrome 70 به بعد شروع به کمک به MEI خواهد کرد. این تضمین می‌کند که ما می‌توانیم قصد مورد نظر کاربر را در مورد پخش خودکار و وب‌سایت‌هایی که معمولاً بازدید می‌کنند، پیش‌بینی کنیم.

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

به تعویق انداختن تغییر برای حمایت از جامعه

هنگامی که این تغییر در کانال Chrome Stable ظاهر شد، جامعه توسعه دهندگان Web Audio - به ویژه توسعه‌دهنده بازی‌های وب و بخش‌های توسعه‌دهنده WebRTC از این انجمن، متوجه شدند.

بازخورد جامعه این بود که بسیاری از بازی‌های وب و تجربیات صوتی وب تحت تأثیر منفی این تغییر قرار می‌گیرند – به‌ویژه، بسیاری از سایت‌هایی که به‌روزرسانی نشده‌اند دیگر صدا را برای کاربران پخش نمی‌کنند. در نتیجه، تیم ما به این نتیجه رسید که ارزش این را دارد که این تغییر را به تأخیر بیندازیم تا به توسعه دهندگان صوتی وب زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم.

علاوه بر این، ما این زمان را به این موارد اختصاص دادیم:

  • به طور جدی در نظر بگیرید که آیا این تغییر سیاست بهترین اقدام بود یا خیر.
  • روش‌هایی را که می‌توانیم به کاهش تعداد وب‌سایت‌های صوتی که تحت تأثیر قرار می‌گیرند کمک کنیم، کاوش کنید.

در مورد اولی، ما در نهایت تصمیم گرفتیم که تغییر خط مشی در واقع برای بهبود تجربه کاربر برای اکثر کاربران ما ضروری است. جزئیات بیشتر در مورد مشکلی که تغییر خط مشی حل می کند را می توانید در بخش بعدی این مقاله بخوانید.

برای دومی، ما تنظیماتی را در پیاده سازی خود برای Web Audio انجام داده ایم که تعداد وب سایت هایی را که در ابتدا تحت تأثیر قرار گرفته اند کاهش می دهد. از میان سایت‌هایی که می‌دانستیم با این تغییر شکسته شده‌اند - که بسیاری از آنها به عنوان نمونه توسط جامعه توسعه بازی‌های وب ارائه شده‌اند - این تنظیم به این معنی است که بیش از 80٪ از آنها به طور خودکار کار می‌کنند. تجزیه و تحلیل و آزمایش ما از این سایت های نمونه را می توان در اینجا مشاهده کرد . این تنظیم جدید با جزئیات بیشتر در زیر توضیح داده شده است.

ما همچنین تغییری برای پشتیبانی از برنامه های WebRTC ایجاد کردیم. در حالی که یک جلسه ضبط فعال وجود دارد، پخش خودکار مجاز خواهد بود.

این تغییر رفتار با هدف حل چه مشکلی است؟

مرورگرها از لحاظ تاریخی در کمک به کاربر در مدیریت صدا ضعیف بوده اند. وقتی کاربران یک صفحه وب را باز می کنند و صدایی را دریافت می کنند که انتظار یا نمی خواستند، تجربه کاربری ضعیفی دارند. این تجربه کاربری ضعیف مشکلی است که ما سعی در حل آن داریم. نویز ناخواسته دلیل اصلی این است که کاربران نمی خواهند مرورگر آنها محتوا را به صورت خودکار پخش کند.

با این حال، گاهی اوقات کاربران می خواهند محتوا به صورت خودکار پخش شود و تعداد قابل توجهی از پخش خودکار مسدود شده در Chrome متعاقبا توسط کاربر پخش می شود.

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

یکی از پیشنهادات ارائه شده توسط انجمن، بی صدا کردن صدای یک برگه به ​​جای توقف پخش خودکار بوده است. با این حال، ما معتقدیم که بهتر است تجربه پخش خودکار را متوقف کنیم تا وب‌سایت از مسدود شدن پخش خودکار آگاه شود و به توسعه‌دهنده وب‌سایت اجازه دهد تا به این موضوع واکنش نشان دهد. برای مثال، در حالی که برخی از توسعه دهندگان ممکن است بخواهند به سادگی صدا را بی صدا کنند، سایر توسعه دهندگان ممکن است ترجیح دهند محتوای صوتی آنها تا زمانی که کاربر فعالانه با محتوا درگیر شود، متوقف شود - در غیر این صورت کاربر ممکن است بخشی از تجربه صوتی را از دست بدهد.

تنظیمات جدید برای کمک به توسعه دهندگان بازی های وب

رایج ترین روشی که توسعه دهندگان از Web Audio API استفاده می کنند، ایجاد دو نوع شی برای پخش صدا است:

توسعه دهندگان صوتی وب یک AudioContext برای پخش صدا ایجاد می کنند. برای از سرگیری صدای خود پس از اینکه خط مشی پخش خودکار به طور خودکار AudioContext خود را به حالت تعلیق درآورد، آنها باید تابع resume() را در این شیء پس از تعامل کاربر با برگه فراخوانی کنند:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

اینترفیس‌های زیادی وجود دارند که از AudioNode به ارث می‌برند، یکی از آنها رابط AudioScheduledSourceNode است. AudioNode هایی که رابط AudioScheduledSourceNode را پیاده سازی می کنند معمولاً به عنوان گره های منبع (مانند AudioBufferSourceNode، ConstantSourceNode و OscillatorNode) نامیده می شوند. گره های منبع یک متد start() را پیاده سازی می کنند.

گره‌های منبع معمولاً قطعه‌های صوتی جداگانه‌ای را نشان می‌دهند که بازی‌ها پخش می‌کنند، برای مثال: صدایی که هنگام جمع‌آوری سکه توسط بازیکن پخش می‌شود یا موسیقی پس‌زمینه‌ای که در مرحله فعلی پخش می‌شود. توسعه دهندگان بازی به احتمال زیاد هر زمان که هر یک از این صداها برای بازی ضروری باشد، تابع start() را روی گره های منبع فراخوانی می کنند.

هنگامی که این الگوی رایج در بازی های وب را شناختیم، تصمیم گرفتیم پیاده سازی خود را به موارد زیر تنظیم کنیم:

یک AudioContext به صورت خودکار از سر گرفته می شود که دو شرط برآورده شود:

  • کاربر با یک صفحه تعامل داشته است.
  • متد start() یک گره منبع فراخوانی می شود.

با توجه به این تغییر، اکثر بازی های وب اکنون زمانی که کاربر بازی را شروع می کند، صدای خود را از سر می گیرند.

حرکت وب به جلو

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

با این وجود، ما می دانیم که اعمال اصلاحات برای وب سایت ها به دلایل مختلف همیشه در کوتاه مدت امکان پذیر نیست:

  • توسعه دهندگان وب ممکن است بر روی یک پروژه جدید متمرکز شوند و نگهداری از یک وب سایت قدیمی بلافاصله امکان پذیر نیست.
  • پورتال های بازی های وب ممکن است کنترلی بر اجرای بازی ها در کاتالوگ خود نداشته باشند و به روز رسانی صدها - اگر نه هزاران - بازی ممکن است برای ناشران وقت گیر و گران باشد.
  • برخی از وب‌سایت‌ها ممکن است به سادگی بسیار قدیمی باشند و – به دلایلی – دیگر نگهداری نمی‌شوند اما همچنان برای اهداف تاریخی میزبانی می‌شوند.

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

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

لازم به ذکر است که این قطعه کد به از سرگیری AudioContext هایی که در یک iframe نمونه سازی شده اند کمکی نمی کند، مگر اینکه این قطعه کد در محدوده محتوای خود iframe گنجانده شود.

ارائه خدمات بهتر به کاربران

برای همراهی با تغییر خط‌مشی، ما همچنین مکانیزمی را برای کاربران معرفی می‌کنیم تا خط‌مشی پخش خودکار را غیرفعال کنند تا مواردی را پوشش دهد که یادگیری خودکار طبق انتظار کار نمی‌کند یا برای وب‌سایت‌هایی که با این تغییر غیرقابل استفاده می‌شوند. این تغییر با خط‌مشی جدید در Chrome 71 اعمال می‌شود و می‌توانید آن را در تنظیمات صدا پیدا کنید. سایت هایی که کاربر می خواهد به پخش خودکار اجازه دهد می توانند به لیست مجاز اضافه شوند.

چگونه MEI برای کاربران جدید ساخته شده است؟

همانطور که قبلا ذکر شد، ما MEI را به طور خودکار در طول زمان بر اساس رفتار کاربر ایجاد می کنیم تا هدف مورد نظر آنها را در رابطه با یک وب سایت خاص با محتوای پخش خودکار پیش بینی کنیم. هر وب سایت در این شاخص امتیازی بین صفر تا یک دارد. نمرات بالاتر نشان می دهد که کاربر انتظار دارد محتوا از آن وب سایت پخش شود.

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

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

یافتن تعادل

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

ما همیشه کاربران خود را در اولویت قرار می دهیم، اما همچنین نمی خواهیم جامعه توسعه وب را ناامید کنیم. گاهی اوقات مرورگر بودن به این معنی است که این دو هدف باید به دقت متعادل شوند. ما معتقدیم که با تنظیماتی که در اجرای این خط‌مشی انجام داده‌ایم و زمان اضافی که برای توسعه‌دهندگان صوتی وب برای به‌روزرسانی کدشان در نظر گرفته‌ایم، با Chrome 71 به این تعادل دست خواهیم یافت.

بازخورد

،

Tom Greenaway
Hongchan Choi

در سپتامبر 2017، تغییراتی را در نحوه مدیریت صدا با خط‌مشی رفتار پخش خودکار در Chrome اعلام کردیم. این تغییر خط‌مشی با Chrome 66 Stable در می ۲۰۱۸ منتشر شد.

پس از بازخورد انجمن توسعه صوتی وب، انتشار بخش صوتی وب از خط‌مشی پخش خودکار را به تاخیر انداختیم تا به توسعه‌دهندگان زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم. ما همچنین تغییراتی را در اجرای خط‌مشی Web Audio ایجاد کرده‌ایم که باعث کاهش تعداد وب‌سایت‌هایی می‌شود که نیاز به تنظیم کد خود دارند - به ویژه بازی‌های وب - و بنابراین تجربه بهتری را برای کاربران خود فراهم می‌کنند.

این تغییر خط مشی اکنون قرار است در دسامبر 2018 با Chrome 71 عرضه شود.

تغییر سیاست دقیقا چه کاری انجام می دهد؟

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

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

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

ما این کار را با نمایه‌ای انجام می‌دهیم که به‌صورت محلی در نمایه Chrome در یک دستگاه ذخیره می‌شود - بین دستگاه‌ها همگام‌سازی نمی‌شود و فقط به عنوان بخشی از آمار کاربران ناشناس به اشتراک گذاشته می‌شود. ما این فهرست را نمایه تعامل رسانه (MEI) می نامیم و می توانید آن را از طریق chrome://media-engagement مشاهده کنید.

MEI تعداد بازدید از یک سایت شامل پخش صوتی بیش از 7 ثانیه را پیگیری می کند. بر اساس MEI کاربر، ما معتقدیم که می‌توانیم بفهمیم که آیا کاربر از یک وب‌سایت خاص انتظار صدا دارد یا نه - و هدف کاربر را در آینده پیش‌بینی کنیم.

اگر کاربر اغلب به دامنه وب سایت اجازه پخش صدا را برای بیش از 7 ثانیه می دهد، در آینده فرض می کنیم که کاربر انتظار دارد این وب سایت حق پخش خودکار صدا را داشته باشد. بنابراین، ما به آن وب سایت حق پخش خودکار صدا را بدون نیاز به تعامل کاربر با یک برگه از آن دامنه می دهیم.

با این حال، این حق به طور نامحدود تضمین نمی شود. اگر رفتار کاربر تغییر کند - به عنوان مثال توقف پخش صدا یا بستن برگه در آستانه 7 ثانیه در طول چندین بازدید - آنگاه حق وب سایت برای پخش خودکار را حذف می کنیم.

هر دو استفاده از عناصر HTML رسانه (ویدئو و صدا) و صدای وب (اشیاء AudioContext نمونه سازی شده جاوا اسکریپ) به MEI کمک خواهند کرد. در آماده‌سازی برای عرضه این خط‌مشی، رفتار کاربر در رابطه با Web Audio از Chrome 70 به بعد شروع به کمک به MEI خواهد کرد. این تضمین می‌کند که ما می‌توانیم قصد مورد نظر کاربر را در مورد پخش خودکار و وب‌سایت‌هایی که معمولاً بازدید می‌کنند، پیش‌بینی کنیم.

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

به تعویق انداختن تغییر برای حمایت از جامعه

هنگامی که این تغییر در کانال Chrome Stable ظاهر شد، جامعه توسعه دهندگان Web Audio - به ویژه توسعه‌دهنده بازی‌های وب و بخش‌های توسعه‌دهنده WebRTC از این انجمن، متوجه شدند.

بازخورد جامعه این بود که بسیاری از بازی‌های وب و تجربیات صوتی وب تحت تأثیر منفی این تغییر قرار می‌گیرند – به‌ویژه، بسیاری از سایت‌هایی که به‌روزرسانی نشده‌اند دیگر صدا را برای کاربران پخش نمی‌کنند. در نتیجه، تیم ما به این نتیجه رسید که ارزش این را دارد که این تغییر را به تأخیر بیندازیم تا به توسعه دهندگان صوتی وب زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم.

علاوه بر این، ما این زمان را به این موارد اختصاص دادیم:

  • به طور جدی در نظر بگیرید که آیا این تغییر سیاست بهترین اقدام بود یا خیر.
  • روش‌هایی را که می‌توانیم به کاهش تعداد وب‌سایت‌های صوتی که تحت تأثیر قرار می‌گیرند کمک کنیم، کاوش کنید.

در مورد اولی، ما در نهایت تصمیم گرفتیم که تغییر خط مشی در واقع برای بهبود تجربه کاربر برای اکثر کاربران ما ضروری است. جزئیات بیشتر در مورد مشکلی که تغییر خط مشی حل می کند را می توانید در بخش بعدی این مقاله بخوانید.

برای دومی، ما تنظیماتی را در پیاده سازی خود برای Web Audio انجام داده ایم که تعداد وب سایت هایی را که در ابتدا تحت تأثیر قرار گرفته اند کاهش می دهد. از میان سایت‌هایی که می‌دانستیم با این تغییر شکسته شده‌اند - که بسیاری از آنها به عنوان نمونه توسط جامعه توسعه بازی‌های وب ارائه شده‌اند - این تنظیم به این معنی است که بیش از 80٪ از آنها به طور خودکار کار می‌کنند. تجزیه و تحلیل و آزمایش ما از این سایت های نمونه را می توان در اینجا مشاهده کرد . این تنظیم جدید با جزئیات بیشتر در زیر توضیح داده شده است.

ما همچنین تغییری برای پشتیبانی از برنامه های WebRTC ایجاد کردیم. در حالی که یک جلسه ضبط فعال وجود دارد، پخش خودکار مجاز خواهد بود.

این تغییر رفتار با هدف حل چه مشکلی است؟

مرورگرها از لحاظ تاریخی در کمک به کاربر در مدیریت صدا ضعیف بوده اند. وقتی کاربران یک صفحه وب را باز می کنند و صدایی را دریافت می کنند که انتظار یا نمی خواستند، تجربه کاربری ضعیفی دارند. این تجربه کاربری ضعیف مشکلی است که ما سعی در حل آن داریم. نویز ناخواسته دلیل اصلی این است که کاربران نمی خواهند مرورگر آنها محتوا را به صورت خودکار پخش کند.

با این حال، گاهی اوقات کاربران می خواهند محتوا به صورت خودکار پخش شود و تعداد قابل توجهی از پخش خودکار مسدود شده در Chrome متعاقبا توسط کاربر پخش می شود.

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

یکی از پیشنهادات ارائه شده توسط انجمن، بی صدا کردن صدای یک برگه به ​​جای توقف پخش خودکار بوده است. با این حال، ما معتقدیم که بهتر است تجربه پخش خودکار را متوقف کنیم تا وب‌سایت از مسدود شدن پخش خودکار آگاه شود و به توسعه‌دهنده وب‌سایت اجازه دهد تا به این موضوع واکنش نشان دهد. برای مثال، در حالی که برخی از توسعه دهندگان ممکن است بخواهند به سادگی صدا را بی صدا کنند، سایر توسعه دهندگان ممکن است ترجیح دهند محتوای صوتی آنها تا زمانی که کاربر فعالانه با محتوا درگیر شود، متوقف شود - در غیر این صورت کاربر ممکن است بخشی از تجربه صوتی را از دست بدهد.

تنظیمات جدید برای کمک به توسعه دهندگان بازی های وب

رایج ترین روشی که توسعه دهندگان از Web Audio API استفاده می کنند، ایجاد دو نوع شی برای پخش صدا است:

توسعه دهندگان صوتی وب یک AudioContext برای پخش صدا ایجاد می کنند. برای از سرگیری صدای خود پس از اینکه خط مشی پخش خودکار به طور خودکار AudioContext خود را به حالت تعلیق درآورد، آنها باید تابع resume() را در این شیء پس از تعامل کاربر با برگه فراخوانی کنند:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

اینترفیس‌های زیادی وجود دارند که از AudioNode به ارث می‌برند، یکی از آنها رابط AudioScheduledSourceNode است. AudioNode هایی که رابط AudioScheduledSourceNode را پیاده سازی می کنند معمولاً به عنوان گره های منبع (مانند AudioBufferSourceNode، ConstantSourceNode و OscillatorNode) نامیده می شوند. گره های منبع یک متد start() را پیاده سازی می کنند.

گره‌های منبع معمولاً قطعه‌های صوتی جداگانه‌ای را نشان می‌دهند که بازی‌ها پخش می‌کنند، برای مثال: صدایی که هنگام جمع‌آوری سکه توسط بازیکن پخش می‌شود یا موسیقی پس‌زمینه‌ای که در مرحله فعلی پخش می‌شود. توسعه دهندگان بازی به احتمال زیاد هر زمان که هر یک از این صداها برای بازی ضروری باشد، تابع start() را روی گره های منبع فراخوانی می کنند.

هنگامی که این الگوی رایج در بازی های وب را شناختیم، تصمیم گرفتیم پیاده سازی خود را به موارد زیر تنظیم کنیم:

وقتی دو شرط برآورده می شود ، یک متن صوتی به طور خودکار از سر گرفته می شود:

  • کاربر با یک صفحه تعامل داشته است.
  • روش شروع () یک گره منبع نامیده می شود.

با توجه به این تغییر ، وقتی کاربر شروع به بازی بازی می کند ، بیشتر بازی های وب صدا خود را از سر می گیرند.

حرکت وب به جلو

به منظور حرکت به جلو پلت فرم وب ، گاهی اوقات لازم است تغییراتی ایجاد کند که می تواند سازگاری را از بین ببرد. متأسفانه ، Audio Autoplay پیچیده است و در این گروه از تغییر قرار می گیرد. اما ایجاد این تغییر برای اطمینان از عدم رکود وب یا از دست دادن لبه ابتکاری خود بسیار مهم است.

با این وجود ، ما می دانیم که اعمال اصلاح برای وب سایت ها به دلایل مختلف همیشه در کوتاه مدت امکان پذیر نیست:

  • توسعه دهندگان وب ممکن است روی یک پروژه جدید متمرکز شوند و نگهداری از یک وب سایت قدیمی بلافاصله امکان پذیر نیست.
  • پورتال های بازی های وب ممکن است کنترل اجرای بازی ها در کاتالوگ خود را نداشته و صدها نفر - اگر نه هزاران نفر - بازی ها را برای ناشران می توانند وقت گیر و گران باشند.
  • برخی از وب سایت ها ممکن است به سادگی بسیار قدیمی باشند و - به یک دلیل یا دلیل دیگر - دیگر نگهداری نمی شوند اما هنوز هم برای اهداف تاریخی میزبان هستند.

در اینجا یک قطعه کد JavaScript کوتاه وجود دارد که ایجاد اشیاء جدید AudioContext را رهگیری می کند و هنگامی که کاربر تعامل های مختلف کاربر را انجام می دهد ، عملکرد رزومه این اشیاء را خودکار می کند. این کد باید قبل از ایجاد هرگونه اشیاء AudioContext در صفحه وب شما اجرا شود - به عنوان مثال ، می توانید این کد را به آن اضافه کنید برچسب صفحه وب خود:

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

لازم به ذکر است که این قطعه کد به از سرگیری AudioContexts که در یک IFRAME فوری می شوند ، کمک نمی کند ، مگر اینکه این قطعه کد در محدوده محتوای خود Iframe گنجانده شود.

خدمت به کاربران ما بهتر

برای همراهی با تغییر سیاست ، ما همچنین مکانیسمی را برای کاربران معرفی می کنیم تا خط مشی AutoPlay را غیرفعال کنند تا مواردی را که یادگیری خودکار مطابق آنچه انتظار می رود ، یا برای وب سایت هایی که با تغییر غیرقابل استفاده هستند ، پوشش دهند. این تغییر با خط مشی جدید در Chrome 71 به پایان می رسد و می توانید در تنظیمات صدا پیدا کنید. سایتهایی که کاربر می خواهد اجازه دهد AutoPlay را به لیست مجاز اضافه کند.

چگونه MEI برای کاربران جدید ساخته شده است؟

همانطور که قبلاً ذکر شد ، ما MEI را به طور خودکار بر اساس رفتار کاربر می سازیم تا قصد مورد نظر خود را با توجه به یک وب سایت خاص با محتوای خودکار پیش بینی کنیم. هر وب سایت در این فهرست نمره ای بین صفر و یک دارد. نمرات بالاتر نشان می دهد که کاربر انتظار دارد محتوا از آن وب سایت پخش شود.

با این حال ، برای پروفایل های جدید کاربر یا اگر کاربر داده های مرور خود را پاک کند ، به جای مسدود کردن AutoPlay در همه جا ، یک لیست قبل از بذر مبتنی بر نمرات MEI جمع آوری شده کاربر ناشناس برای تعیین اینکه کدام وب سایت ها می توانند خودکار باشند ، استفاده می شود. این داده ها فقط وضعیت اولیه MEI را در ایجاد نمایه کاربر تعیین می کند. از آنجا که کاربر وب را مرور می کند و با وب سایت ها با محتوای AutoPlay ارتباط برقرار می کند ، MEI شخصی آنها بر پیکربندی پیش فرض غلبه می کند.

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

یافتن تعادل

ما مستندات جدیدی را ارسال کرده ایم تا بینش بیشتری در مورد روند تصمیم گیری و منطقی طراحی این سیاست ارائه دهیم. و همچنین مستندات جدید در مورد نحوه عملکرد لیست سایت قبل از بذر .

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

بازخورد

،

Tom Greenaway
Hongchan Choi

در سپتامبر 2017 ما تغییر آینده در نحوه برخورد صوتی با سیاست رفتار Autoplay در Chrome را اعلام کردیم. این تغییر سیاست با پایدار Chrome 66 در ماه مه 2018 منتشر شد.

پس از بازخورد از انجمن توسعه صوتی وب ، انتشار بخش صوتی وب خط مشی AutoPlay را به تأخیر انداختیم تا به توسعه دهندگان زمان بیشتری برای به روزرسانی وب سایت های خود بدهیم. ما همچنین تغییراتی در اجرای خط مشی برای صوتی وب ایجاد کرده ایم که باعث می شود تعداد وب سایت هایی که برای تنظیم کد آنها - به ویژه بازی های وب - نیاز دارند ، کاهش دهد و بنابراین تجربه بهتری را برای کاربران ما فراهم می کند.

این تغییر سیاست اکنون قرار است در دسامبر سال 2018 با Chrome 71 به پایان برسد.

تغییر سیاست دقیقاً چه کاری انجام می دهد؟

AutoPlay نامی است که به یک قطعه محتوا داده می شود که بلافاصله پس از بارگیری یک صفحه وب پخش می شود. برای وب سایت هایی که انتظار می رود بتوانند محتوای خود را به صورت خودکار انجام دهند ، این تغییر به طور پیش فرض از پخش جلوگیری می کند. در بیشتر موارد ، پخش از سر گرفته می شود اما در برخی دیگر ، یک تنظیم کوچک با کد مورد نیاز خواهد بود. به طور خاص ، توسعه دهندگان باید در صورت تعامل کاربر با صفحه وب ، کدی را که محتوای آنها را از سر می گیرد ، اضافه کنند.

با این حال ، اگر کاربر با محتوای AutoPlay وارد صفحه شود و از صفحه ای با همان منشاء به آن صفحه حرکت کند ، پس هرگز آن محتوا مسدود نمی شود. برای مثال های بیشتر ، پست وبلاگ قبلی ما را در خط مشی AutoPlay بخوانید.

علاوه بر این ، ما یک اکتشافی برای یادگیری از رفتار گذشته کاربران با توجه به وب سایت هایی که Autoplay Audio را در اختیار شما قرار می دهد ، اضافه کردیم. ما تشخیص می دهیم که کاربران به طور مرتب اجازه می دهند صوتی بیش از 7 ثانیه در بیشتر بازدیدهای خود از یک وب سایت پخش شود و AutoPlay را برای آن وب سایت فعال کند.

ما این کار را با شاخصی انجام می دهیم که به صورت محلی در هر نمایه Chrome در یک دستگاه ذخیره می شود - در دستگاه ها همگام سازی نمی شود و فقط به عنوان بخشی از آمار کاربر ناشناس به اشتراک گذاشته می شود. ما این فهرست را شاخص مشارکت رسانه ای (MEI) می نامیم و می توانید آن را از طریق Chrome مشاهده کنید: // Media- Engagement.

MEI پیگیری می کند که تعداد بازدید از یک سایت شامل پخش صوتی است که بیش از 7 ثانیه طول دارد. بر اساس MEI کاربر ، ما معتقدیم که می توانیم درک کنیم که آیا کاربر از یک وب سایت خاص انتظار صدا را دارد یا خیر - و قصد کاربر را در آینده پیش بینی می کند.

اگر کاربر اغلب به بیش از 7 ثانیه به صدای پخش دامنه وب سایت اجازه می دهد ، در آینده فرض می کنیم که کاربر انتظار دارد این وب سایت حق دارد صدا را به صورت خودکار انجام دهد. بنابراین ، ما به این وب سایت حق می دهیم که صدا را به صورت خودکار انجام دهد بدون اینکه کاربر را ملزم به تعامل با یک برگه از آن دامنه کند.

با این حال ، این حق به طور نامحدود تضمین نمی شود. اگر رفتار کاربر تغییر می کند - به عنوان مثال متوقف کردن پخش صوتی یا بستن برگه در آستانه 7 ثانیه در طول چندین بازدید - آنگاه حق وب سایت را برای خودکار سازی حذف می کنیم.

هر دو استفاده از عناصر HTML رسانه ای (فیلم و صوتی) و صوتی وب (اشیاء AudioContext سریع جاوا اسکریپت) به MEI کمک می کنند. در آماده سازی برای اجرای این رفتار کاربر در رابطه با صدای وب ، از Chrome 70 و به بعد به MEI کمک می کند. این امر اطمینان حاصل می کند که ما قبلاً قادر به پیش بینی هدف مورد نظر کاربر با توجه به اتوپل و وب سایتهایی هستند که معمولاً از آنها بازدید می کنند.

لازم به ذکر است که اگر صفحه وب والدین که Iframe را تعبیه می کند ، این حق را به سمت iframe داده شده گسترش می دهد .

تأخیر در تغییر برای حمایت از جامعه

انجمن توسعه دهنده صوتی وب - به ویژه بخش های توسعه دهنده بازی های وب و بخش های توسعه دهنده WEBRTC از این جامعه - هنگامی که این تغییر در کانال پایدار Chrome ظاهر شد ، توجه کردند.

بازخورد جامعه این بود که بسیاری از بازی های وب و تجربیات صوتی وب تحت تأثیر این تغییر قرار می گیرند - به طور خاص ، بسیاری از سایت هایی که به روز نشده اند ، دیگر صدا را برای کاربران پخش نمی کنند. در نتیجه ، تیم ما تصمیم گرفت که ارزش تأخیر در این تغییر را داشته باشد تا به توسعه دهندگان صوتی وب فرصت بیشتری برای به روزرسانی وب سایت های خود بدهد.

علاوه بر این ، ما این زمان را به این موارد رساندیم:

  • به طور جدی در نظر بگیرید که آیا این تغییر سیاست بهترین دوره عمل بوده است یا خیر.
  • راه هایی را که می توانیم به کاهش تعداد وب سایت های صوتی که تحت تأثیر قرار می گیرند ، به شما کمک کنیم.

برای سابق ، ما در نهایت تصمیم گرفتیم که تغییر سیاست در واقع برای بهبود تجربه کاربر برای اکثر کاربران ما ضروری است. جزئیات بیشتر در مورد چه مشکلی تغییر سیاست را می توان در بخش بعدی این مقاله خواند.

برای دومی ، ما برای اجرای ما برای اجرای صوتی تنظیم شده ایم که باعث کاهش تعداد وب سایت هایی که در ابتدا تحت تأثیر قرار گرفته اند ، کاهش می یابد. از میان سایتهایی که می دانستیم با تغییر شکسته شده اند - بسیاری از آنها به عنوان نمونه توسط جامعه توسعه بازی های وب ارائه شده است - این تنظیم به این معنی بود که بیش از 80 ٪ از آنها به طور خودکار کار می کنند. تجزیه و تحلیل و آزمایش ما از این سایت های مثال را می توان در اینجا مشاهده کرد . این تنظیم جدید با جزئیات بیشتر در زیر شرح داده شده است.

ما همچنین برای پشتیبانی از برنامه های WEBRTC تغییری ایجاد کردیم. در حالی که یک جلسه ضبط فعال وجود دارد ، Autoplay مجاز خواهد بود.

این تغییر رفتار با هدف حل چیست؟

مرورگرها از نظر تاریخی در کمک به کاربر برای مدیریت صدا ضعیف بوده اند. وقتی کاربران یک صفحه وب را باز می کنند و صدایی را که انتظار ندارند یا نمی خواستند دریافت می کنند ، تجربه کاربر ضعیفی دارند. این تجربه کاربر ضعیف مشکلی است که ما سعی در حل آن داریم. سر و صدای ناخواسته دلیل اصلی این است که کاربران نمی خواهند مرورگر خود را به محتوای خودکار بپردازند.

با این حال ، گاهی اوقات کاربران می خواهند محتوا به صورت خودکار به صورت خودکار باشد و تعداد معناداری از اتوپل های مسدود شده در Chrome متعاقباً توسط کاربر بازی می شود.

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

یکی از پیشنهادهایی که توسط جامعه مطرح شده است این بوده است که به جای مکث خودکار ، صدای یک برگه را نادیده بگیرد. با این حال ، ما معتقدیم که بهتر است تجربه AutoPlay را متوقف کنیم تا وب سایت آگاه باشد که Autoplay مسدود شده است و به توسعه دهنده وب سایت اجازه می دهد تا نسبت به این امر واکنش نشان دهد. به عنوان مثال ، در حالی که برخی از توسعه دهندگان ممکن است بخواهند صدا را به سادگی صدا کنند ، سایر توسعه دهندگان ممکن است ترجیح دهند محتوای صوتی آنها متوقف شود تا زمانی که کاربر به طور فعال با محتوا درگیر نشود - در غیر این صورت کاربر ممکن است بخشی از تجربه صوتی را از دست بدهد.

تنظیمات جدید برای کمک به توسعه دهندگان بازی های وب

متداول ترین روش توسعه دهندگان از API صوتی وب با ایجاد دو نوع اشیاء برای پخش صدا:

توسعه دهندگان صوتی وب یک متن صوتی برای پخش صدا ایجاد می کنند. به منظور از سرگیری صدای آنها پس از خط مشی AutoPlay ، به طور خودکار AudioContext خود را به حالت تعلیق درآورد ، آنها پس از تعامل کاربر با برگه ، باید با عملکرد رزومه () روی این شی تماس بگیرند:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

رابط های زیادی وجود دارد که از Audionode به ارث می برند ، که یکی از آنها رابط AudioscheduleDsourcenode است. Audionodes که رابط AudiOschEledSourCenode را پیاده سازی می کنند ، معمولاً به عنوان گره های منبع (مانند Audiobuffersourcenode ، ConstantSourCenode و Osillatornode) گفته می شوند. گره های منبع یک روش شروع () را پیاده سازی می کنند.

گره های منبع معمولاً نمایانگر قطعه های صوتی فردی هستند که بازی ها بازی می کنند ، به عنوان مثال: صدایی که وقتی پخش کننده یک سکه یا موسیقی پس زمینه را جمع می کند که در مرحله فعلی پخش می شود ، پخش می شود. توسعه دهندگان بازی به احتمال زیاد هر زمان که هر یک از این صداها برای بازی لازم باشد ، عملکرد Start () را روی گره های منبع فراخوانی می کنند.

هنگامی که این الگوی مشترک را در بازی های وب تشخیص دادیم ، تصمیم گرفتیم اجرای خود را به موارد زیر تنظیم کنیم:

وقتی دو شرط برآورده می شود ، یک متن صوتی به طور خودکار از سر گرفته می شود:

  • کاربر با یک صفحه تعامل داشته است.
  • روش شروع () یک گره منبع نامیده می شود.

با توجه به این تغییر ، وقتی کاربر شروع به بازی بازی می کند ، بیشتر بازی های وب صدا خود را از سر می گیرند.

حرکت وب به جلو

به منظور حرکت به جلو پلت فرم وب ، گاهی اوقات لازم است تغییراتی ایجاد کند که می تواند سازگاری را از بین ببرد. متأسفانه ، Audio Autoplay پیچیده است و در این گروه از تغییر قرار می گیرد. اما ایجاد این تغییر برای اطمینان از عدم رکود وب یا از دست دادن لبه ابتکاری خود بسیار مهم است.

با این وجود ، ما می دانیم که اعمال اصلاح برای وب سایت ها به دلایل مختلف همیشه در کوتاه مدت امکان پذیر نیست:

  • توسعه دهندگان وب ممکن است روی یک پروژه جدید متمرکز شوند و نگهداری از یک وب سایت قدیمی بلافاصله امکان پذیر نیست.
  • پورتال های بازی های وب ممکن است کنترل اجرای بازی ها در کاتالوگ خود را نداشته و صدها نفر - اگر نه هزاران نفر - بازی ها را برای ناشران می توانند وقت گیر و گران باشند.
  • برخی از وب سایت ها ممکن است به سادگی بسیار قدیمی باشند و - به یک دلیل یا دلیل دیگر - دیگر نگهداری نمی شوند اما هنوز هم برای اهداف تاریخی میزبان هستند.

در اینجا یک قطعه کد JavaScript کوتاه وجود دارد که ایجاد اشیاء جدید AudioContext را رهگیری می کند و هنگامی که کاربر تعامل های مختلف کاربر را انجام می دهد ، عملکرد رزومه این اشیاء را خودکار می کند. این کد باید قبل از ایجاد هرگونه اشیاء AudioContext در صفحه وب شما اجرا شود - به عنوان مثال ، می توانید این کد را به آن اضافه کنید برچسب صفحه وب خود:

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

لازم به ذکر است که این قطعه کد به از سرگیری AudioContexts که در یک IFRAME فوری می شوند ، کمک نمی کند ، مگر اینکه این قطعه کد در محدوده محتوای خود Iframe گنجانده شود.

خدمت به کاربران ما بهتر

برای همراهی با تغییر سیاست ، ما همچنین مکانیسمی را برای کاربران معرفی می کنیم تا خط مشی AutoPlay را غیرفعال کنند تا مواردی را که یادگیری خودکار مطابق آنچه انتظار می رود ، یا برای وب سایت هایی که با تغییر غیرقابل استفاده هستند ، پوشش دهند. این تغییر با خط مشی جدید در Chrome 71 به پایان می رسد و می توانید در تنظیمات صدا پیدا کنید. سایتهایی که کاربر می خواهد اجازه دهد AutoPlay را به لیست مجاز اضافه کند.

چگونه MEI برای کاربران جدید ساخته شده است؟

همانطور که قبلاً ذکر شد ، ما MEI را به طور خودکار بر اساس رفتار کاربر می سازیم تا قصد مورد نظر خود را با توجه به یک وب سایت خاص با محتوای خودکار پیش بینی کنیم. هر وب سایت در این فهرست نمره ای بین صفر و یک دارد. نمرات بالاتر نشان می دهد که کاربر انتظار دارد محتوا از آن وب سایت پخش شود.

با این حال ، برای پروفایل های جدید کاربر یا اگر کاربر داده های مرور خود را پاک کند ، به جای مسدود کردن AutoPlay در همه جا ، یک لیست قبل از بذر مبتنی بر نمرات MEI جمع آوری شده کاربر ناشناس برای تعیین اینکه کدام وب سایت ها می توانند خودکار باشند ، استفاده می شود. این داده ها فقط وضعیت اولیه MEI را در ایجاد نمایه کاربر تعیین می کند. از آنجا که کاربر وب را مرور می کند و با وب سایت ها با محتوای AutoPlay ارتباط برقرار می کند ، MEI شخصی آنها بر پیکربندی پیش فرض غلبه می کند.

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

یافتن تعادل

ما مستندات جدیدی را ارسال کرده ایم تا بینش بیشتری در مورد روند تصمیم گیری و منطقی طراحی این سیاست ارائه دهیم. و همچنین مستندات جدید در مورد نحوه عملکرد لیست سایت قبل از بذر .

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

بازخورد