إضافة بادئة للرابط - تفصيل صغير يوفر دقائق

في نموذج تقصير الروابط، ستدخل allegro.pl. معظم أدوات التقصير ستخبرك بأن هذا ليس عنوان URL صحيحًا وتطلب منك إدخاله مرة أخرى مع إضافة https:// في البداية. أما موقع cutty.dev فسيضيف https:// تلقائيًا ويستمر في العملية.

هذا يبدو كميزة لا تستحق حتى الذكر. في الممارسة العملية، الفرق بين:

• "لصقتُ الرابط، حصلتُ على رابط قصير، أغلق النافذة" (ثانيتان)
• "لصقتُ الرابط، خطأ، أقرأ الرسالة، أضيف https، مرة أخرى، حصلتُ على الرابط" (15-20 ثانية)

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

ما الذي يفعله cutty.dev بالضبط

لقد ألصقت النص في النموذج. قبل الإرسال إلى الخادم، يتحقق JavaScript مما إذا كان النص يبدأ ببروتوكول معين (http://، https://، ftp://، mailto: وما إلى ذلك). إذا لم يكن كذلك، يفترض النظام أنه مجرد نطاق بدون بروتوكول ويضيف https:// في البداية.

أي:

• allegro.pl → https://allegro.pl
• github.com/twoj-profil/projekt → https://github.com/twoj-profil/projekt
• www.gazeta.pl → https://www.gazeta.pl

وإذا كان بروتوكول موجودًا بالفعل (حتى لو كان غير صحيح)، يتركه النظام كما هو ويواصل التحقق:

• http://example.com → يبقى http://example.com (مسموح)
• ftp://example.com → مرفوض (فقط http/https)
• javascript:alert(1) → مرفوض (حماية من XSS)

لماذا أنا أعاني من هذا والآخرين لا؟

معظم أدوات تقصير الروابط تقوم بمصادقة عنوان URL القياسي عبر new URL(string). مُنشئ URL في المتصفح/جافاسكريبت صارم — إذا لم يكن هناك بروتوكول، فإنه يرمي خطأً. الإخراج الافتراضي لـ new URL("allegro.pl") هو TypeError.

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

الحل يتطلب خمسة أسطر من كود JavaScript:

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalsza walidacja przez new URL(normalized)
}

خمس أسطر من الكود، وعشر ثوانٍ أقل من الإحباط لكل مستخدم في اليوم. لا أعرف سبب عدم قيام معظم السوق بذلك. ربما لأن «المعيار» يعني «كيفية عمل مُنشئ عناوين URL».

التفاصيل الصغيرة في تجربة المستخدم ذات أهمية غير متناسبة

يحتوي موقع cutty.dev على عدة أشياء غير مدرجة في أي قائمة ميزات، لأن كل منها بمفرده يبدو تافهًا:

• تنظيف المسافات البيضاء قبل التحقق من الصحة — الرابط المُلصق الذي يحتوي على مسافة في النهاية لا يسبب خطأً
• الحفاظ على التجزئة (Hash) — https://example.com/page#section يحافظ على #section بعد الاختصار
• الحفاظ على سلاسل الاستعلام — ?utm_source=test يمر دون قصّ
• ترقية البروتوكول تلقائياً — تحويل http:// إلى https:// عندما يدعم الرابط الأصلي بروتوكول TLS (مخطط له، وليس نشطاً بعد)
• النطاقات الدولية (IDN) — يتم تحويل źdźbło.pl إلى صيغة Punycode تلقائياً
• الأحرف البولندية في السلاغ — يتم استبدالها تلقائياً بـ ASCII عند إنشاء نهاية مخصصة (różowy-link → rozowy-link)
• كشف البروتوكولات الخطرة — يتم رفض javascript: و data: و file: و mailto: مع رسالة محددة

يوفر كلٌ من هذه التفاصيل لشخصٍ ما ما بين 5 إلى 30 ثانية ولحظةً من الإحباط. مجتمعةً، يصنع هذا الفرق بين عبارة "أعجبني هذا التطبيق" وعبارة "يعمل بشكلٍ مقبول".

ماذا بعد مع تفاصيل واجهة المستخدم (UX)

قائمة الأشياء التي أريد القيام بها في المستقبل:

• اللصق الذكي — اكتشف عندما يلصق المستخدم نصًا يحتوي على رابط بين كلمات أخرى، واستخرج الرابط نفسه فقط
• اللصق الدفعي — قائمة الروابط المُلصقة (واحد لكل سطر) تنشئ العديد من الروابط القصيرة في وقت واحد
• الملحق المقترحة — بناءً على عنوان الصفحة الهدف، اقترح 3 نهايات علامة تجارية للاختيار منها
• معاينة OG التلقائية — اعرض معاينة لبطاقات Open Graph فورًا بعد لصق الرابط، قبل النقر

كل واحدة من هذه هي أيضًا "دالة مكونة من خمسة أسطر تبدو بلا أهمية". الفرق بين الأداة التي تكون مقبولة والأداة التي تريد استخدامها يوميًا يكمن في كل ما سبق معًا.

جرّب بنفسك

ألصق شيئًا — allegro.pl أو github.com أو news.ycombinator.com. سيقوم النظام بإضافة البروتوكول تلقائيًا والمضي قدمًا. بدون انتظار، بدون أخطاء، بدون "حاول مرة أخرى".

إذا كان هذا النوع من تفاصيل تجربة المستخدم يثير اهتمامك، فأخبرني إلى أي اتجاه يجب أن نمضي قدمًا. hello@cutty.dev.