Google Tabletop يحوّل الطلبات النصية إلى 4 أنواع من التطبيقات المصغّرة للمجموعات

قصة مألوفة: تُناقَش الرحلة في محادثة جماعية، وخيارات الإقامة موزّعة على روابط منفصلة، والمصروفات تُحسب في جدول، بينما لا يتذكّر القرار الأخير إلا شخص واحد. تقترح Google جمع هذه المهمة في مساحة تفاعلية مشتركة. في تجربة Tabletop يضيف المستخدم المواد، ويصف الأداة التي يحتاجها، فيحصل على تطبيق مصغّر يستطيع أفراد المجموعة استخدامه في الوقت نفسه.

وبالنسبة للمطوّرين ومديري المنتجات، يبرز هنا سؤال محدّد: أي سير عمل صغير يمكن إسناده اليوم إلى واجهة تُنشأ عند الطلب؟ وإذا احتاج شخص إلى أداة تصويت واحدة لأمسية واحدة، فكم عدد الإعدادات التي يقبل أن يمرّ بها للوصول إلى النتيجة؟

ما الذي عرضته Google بالضبط

في الإعلان الرسمي المنشور في 11 نوفمبر، تصف Google أربعة أمثلة: مسار رحلة، وتصويت على العشاء، وتقسيم المصروفات، وجدول بطولة. يمكن البدء بطلب موجّه إلى @tabletop أو بقالب جاهز. وتتمثل المواد المصدرية في الروابط والملفات وأفكار المستخدم.

تتم مشاركة المساحة الجاهزة عبر دعوة برابط. ويمكن لعدة مشاركين العمل فيها في الوقت الفعلي؛ وتشبّه Google هذا الوضع بالعمل المشترك في Google Docs. في البداية تتوفر التجربة عبر قائمة انتظار في الولايات المتحدة للمستخدمين من عمر 18 عامًا فأكثر.

لنتخيّل رحلة لستة أصدقاء. أحدهم يجمع خيارات الإقامة، وآخر يقترح البرنامج، وثالث يريد أن يفهم الميزانية مسبقًا. في المراسلات المعتادة تختلط هذه النقاشات سريعًا. ومثال على طلب لهذا السيناريو قد يكون: «ابنِ مسار الرحلة من هذه المواد وأضف تصويتًا على العشاء». هذا توضيح لاستخدام محتمل، وليس نتيجة اختبار أجريناه.

تظهر قيمة هذا النهج عندما يكون من الأسهل على المشاركين فتح رابط واتخاذ قرار من استعادة السياق من الرسائل. وهذا الانتقال تحديدًا هو ما يجب اختباره: هل أصبح لدى المجموعة وسيلة مريحة لاتخاذ القرار، أم أنها مجرد تبويب آخر؟

لماذا يهم هذا فرق المنتجات

يمنحنا Tabletop سببًا للنظر في المهام الأصغر من أن تستحق منتجًا مستقلًا، لكنها تستهلك الوقت بانتظام. الاتفاق على قائمة الطعام، وتوزيع المشتريات، وجمع المشاركين في بطولة صغيرة. لكل عملية بيانات إدخال، وعدة إجراءات، ونقطة إنجاز واضحة.

الفرضية المنتجية هنا بسيطة: قد تُخدَم بعض هذه المهام بتطبيق يُنشأ من أجل حدث بعينه. وتتحدّد قيمته بما إذا كانت المجموعة قد وصلت إلى نتيجة. ولاختبار هذه الفرضية، من الأفضل عدّ التصويتات المكتملة والخطط المتفق عليها لا عدد الشاشات المنشأة.

ينبغي لمؤسسي خدمات العمل المشترك مراجعة سيناريوهات مستخدميهم. أين يجمع الناس في كل مرة الجدول نفسه يدويًا؟ وأين ينقلون النتائج بين المحادثة والنموذج؟ هذه المواضع مناسبة لتجربة صغيرة في توليد الواجهات. يمكن البدء بعملية واحدة متكررة ومقارنتها بالطريقة المعتادة في العمل.

وبالنسبة للمطوّر، هذا أيضًا سؤال عن بنية التطبيق. الشاشة المشتركة تتطلب حالة متسقة: إذا غيّر شخصان البيانات في الوقت نفسه، فعلى الآخرين أن يفهموا أي نتيجة حُفظت. وتوليد نموذج جميل لا يحل هذه المسألة بمفرده.

ما الذي لا يزال بحاجة إلى اختبار

لا يتيح الإعلان القصير الوعد بوقت بناء محدد، أو بتوفير في الميزانية، أو بموثوقية الحسابات. كما لا توجد فيه تفاصيل عن تصدير الشيفرة وواجهة API وسلوك التطبيقات المعقدة. ومن المبكر اعتبار Tabletop بديلًا جاهزًا للأدوات الداخلية في الشركات.

بعد الحصول على الوصول، كنت سأتحقق من ثلاثة أمور: هل يستطيع المشارك المدعو أن يفهم الأداة دون شرح، وهل تُحفظ التغييرات عند العمل المتزامن، وهل تحسب الأداة المصروفات بشكل صحيح. ومن المفيد أيضًا النظر في مدى سهولة تصحيح خطأ في المنطق المُنشأ.

الخلاصة العملية لمدير المنتج: خذ مهمة اتفاق صغيرة واحدة وقِس ما إذا كانت الواجهة المشتركة تساعد على إنجازها. Tabletop مثير للاهتمام بوصفه فرصة لاختبار هذه الفرضية. والجواب سيأتي من سلوك المشاركين: هل سيستخدمون التطبيق، أم سيواصلون اتخاذ القرارات بالتفاعلات في المحادثة؟