Emdy: قارئ Markdown مفتوح المصدر

كل أداة استخدمتُها لقراءة Markdown كانت مبنية للكتابة

كنتُ أستقبل ملفات .md باستمرار. خطط مشاريع من Claude. كنتُ أفتحها في VS Code أو iA Writer لأنها ما كان متاحًا، وكان ذلك مبالغة. هذه تطبيقات مبنية للتحرير، وأنا أردتُ القراءة فقط.

macOS لا يوفّر طريقة أصلية لعرض Markdown. Quick Look يعرض الكود المصدري. الخيارات الحالية إمّا محررات برمجية، أو أدوات كتابة، أو عارضات في المتصفح مع مقايضات خصوصية.

الذكاء الاصطناعي قلب استخدام Markdown

أدوات Markdown افترضت أنك الكاتب. الذكاء الاصطناعي غيّر من يقف على الطرف الآخر. معظم ملفات .md التي أتعامل معها تصلني من شخص آخر، وأنا فقط أريد قراءتها. الأدوات لا تزال تفترض أنني أريد التحرير.

كلما زاد عدد الأشخاص الذين يستقبلون Markdown مُولَّدًا بالذكاء الاصطناعي، اتسعت الفجوة بين من يكتب ومن يقرأ.

قراءة المشهد قبل كتابة الكود

البحث المكتبي أولًا. جمعتُ ٢٥ مصدرًا عبر منتديات Apple Community، وخيوط دعم OpenAI، وHacker News، وReddit، ومدونات المطورين، ثم صنّفتُ كل واحد بالتاريخ والشدة وما كشفه عن المشكلة.

نفس الاحتكاك استمر بالظهور. أدوات الذكاء الاصطناعي تُخرج Markdown افتراضيًا، والأشخاص الذين يستقبلون تلك الملفات لا يملكون غالبًا طريقة جيدة لقراءتها. تتبّعتُ تدرجًا في الشدة بين الشرائح. لمن يستقبل ملف .md بين الحين والآخر، هذه مضايقة خفيفة. للعاملين في المعرفة الذين يتلقون Markdown أسبوعيًا، احتكاك حقيقي. للفرق التي تشارك ملاحظات Obsidian عبر التخصصات، عائق فعلي للمستقبلين الذين لا يستخدمون Obsidian.

ثم استبيان قصير. كل مستخدم نشط لـ Markdown ذكر أدوات الذكاء الاصطناعي كمصدر لملفات .md. ٨٠٪ قالوا إن نسخ النص المنسّق إلى البريد أو Docs أو Slack هو أهم ميزة يريدونها. الحل البديل الأكثر شيوعًا كان طلب تحويل الملف إلى PDF. لم يطلب أحد التحرير.

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

الجميع يبني الشيء نفسه

راجعتُ ١٣ منافسًا مباشرًا و٨ منافسين غير مباشرين (حلول بديلة مثل VS Code، وعرض GitHub، وpandoc، والعارضات في المتصفح)، ثم رسمتُهم على محورين: القراءة مقابل الكتابة، والبساطة مقابل القوة.

خريطة التموضع التنافسية. ربع "القارئ البسيط" كان مشغولًا، لكن بدون فائز واضح.

التطبيقات المُرسّخة (Typora بسعر $15، iA Writer بسعر $50، Obsidian باشتراك) كلها تستهدف الكتّاب. تتعامل مع عرض Markdown جيدًا، لكنها تأتي بواجهة محرر لا داعي لها حين تريد فقط قراءة ملف ولّده Claude لك.

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

الاكتشاف كان الفجوة الأخرى. معظم الناس لا يبحثون عن "قارئ Markdown" حين يستلمون ملف .md. يطلبون من المُرسِل تحويله إلى PDF، أو يلصقون المحتوى في أداة متصفح. تحدي المنتج وتحدي التوزيع بنفس الحجم.

الالتزام بالنطاق

المنتج البديهي هنا هو "محرر Markdown، لكن أفضل". ذلك الربع مزدحم، وسأخسر من اليوم الأول.

عرّفتُ Emdy بما لن يكون. لا تحرير. لا تصفّح تفرّعي للمجلدات. كل ميزة تُضاف للكتّاب كانت ستُخفّف من تجربة القراءة.

الالتزام بهذا الخط صار المبدأ التصميمي الوحيد الذي أعود إليه كلما ظهر ضغط "لكن ماذا لو أضفنا أيضًا…" لاحقًا.

مبادئ تصميم Emdy

بعد أن تحدّد النطاق بما لن يكون Emdy، كتبتُ القواعد التي ستُمسك ذلك الخط. خرجت من الموجز التصميمي، وصمدت أمام كل نقاش حول الميزات بعد ذلك.

1. 01
   القراءة هي المنتج بالكامل كل قرار يمر عبر سؤال واحد: هل هذا يجعل قراءة ملف Markdown أفضل؟ إن كانت الإجابة لا، فهو خارج النطاق.
2. 02
   الأشخاص غير التقنيين يجب ألا يضيعوا أبدًا لا شاشة تفضيلات بثلاثين خيارًا. لا أوامر طرفية. لا مصطلحات معقّدة. مدير تسويق لم يسمع بـ Markdown يجب أن يستطيع الضغط مرتين على ملف .md وقراءته.
3. 03
   احترام خصوصية المستخدم Emdy يعمل بالكامل على جهاز المستخدم. لا تتبّع للميزات، لا تحليلات، لا تسجيل مطلوب، لا جمع لأي بيانات شخصية. الاتصال الوحيد بالشبكة الذي يقوم به التطبيق هو التحقق من التحديثات.

تصميم اللحظة التي يضغط فيها أحدهم مرتين على ملف .md

رسمتُ أربع رحلات. الرحلة الأساسية: شخص غير تقني يستقبل ملف .md من مطور أو تصدير مُولَّد بالذكاء الاصطناعي، ويريد قراءته دون تثبيت محرر آخر. لا يبحث عن قارئ. يكتشف Emdy عبر الشخص الذي أرسل له الملف.

هذه البصيرة الواحدة شكّلت استراتيجية التوزيع حول التوصية الشفهية من المطورين. إذا عرف المطورون بوجود Emdy، يمكنهم التوصية به. المستخدمون غير التقنيين يدخلون من الباب الجانبي.

الرحلة الأعلى احتكاكًا كانت التثبيت الأول. Gatekeeper في macOS يمكن أن يحجب التطبيقات غير الموقّعة عند التشغيل الأول، لهذا كان التوقيع والتوثيق ضروريين رغم الكلفة. جعل Emdy المعالج الافتراضي لملفات .md لا يزال خطوة يدوية عبر Finder، مما يعني وجود مخاطرة حقيقية للانقطاع بين "مُثبَّت" و"مُدمَج".

تصميم حالات الفشل

رسمتُ الخدمة الكاملة عبر ثلاث طبقات: ما يراه المستخدم، وما يفعله التطبيق، وما يوفّره macOS. أكثر مخرج نافع كان جرد حالات الفشل. كل طريقة يمكن أن ينكسر بها التطبيق موثّقة (ملفات غير قابلة للقراءة، Markdown مُشوَّه، فشل تحميل صور عن بُعد، ملفات تُحذف أثناء فتحها) مع تصميم سلوك تعافٍ لكل حالة.

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

تحديد الاتجاه البصري

كان على الاتجاه البصري أن يحمل عبر ثلاثة أسطح: التطبيق، والأيقونة، والموقع التسويقي.

تصميم التطبيق

التطبيق مستلهم من Braun وDieter Rams: عملي، هادئ، ملموس. لوحة الألوان تشمل Warm وCool وNeutral وFresh وNeon، مع أوضاع فاتح وداكن لكل منها.

واجهة القراءة، الوضع الفاتح

إعدادات الألوان، الوضع الداكن

أيقونة التطبيق

مرّت الأيقونة بعدة جولات. بدأت بمراجع مباشرة من Braun: مُشغّل أسطوانات، حرف طيني، حامل كتاب. مرّت بمفاهيم جهاز قراءة وشاشة قديمة. عبر نحو عشر تكرارات، صار الرمز أبسط وأكثر ثقة.

الموقع التسويقي

استكشفتُ تسعة اتجاهات لموقع تسويقي قبل الاستقرار. معظمها حاول أن يشرح الكثير. الاتجاه الذي نجح عرض مقارنة قبل-وبعد بين Markdown الخام والمخرجات المعروضة، ينقل القيمة في تمرير واحد.

ثلاثة من الاستكشافات المبكرة:

Warm Machine

Quiet Library

Playful Precision

ست طبقات من الوصولية

مواصفة من ست طبقات تستهدف توافق WCAG 2.1 AA:

1. معالم دلالية مع تنقل تخطّي، ومناطق nav وmain مناسبة.
2. أدوار ARIA وتسميات على كل زر أيقونة، والنوافذ المنبثقة كـ dialogs، ولوحة الأوامر كـ combobox مع listbox، والإعدادات كـ radiogroups، والشريط الجانبي بـ aria-current.
3. مؤشرات تركيز بحلقات :focus-visible مرئية، مُخفاة عند التفاعل بالفأرة.
4. حصر التركيز داخل النوافذ المنبثقة مع تدوير Tab/Shift+Tab واستعادة التركيز عند الإغلاق.
5. مناطق حيّة تُعلن نتائج البحث، وتغييرات التكبير، وتحميل الملفات، والأخطاء.
6. حركة وتباين مُخفَّضان، مع احترام prefers-reduced-motion والتحقق من تباين WCAG AA عبر كل توكن لوني.

الاختبار كان ما إذا كان يمكن استخدام التطبيق جيدًا بدون فأرة، وقراءته بصوت عالٍ تسلسليًا بواسطة قارئ شاشة، ويبقى مؤدّبًا تحت prefers-reduced-motion.

مجاني، مفتوح المصدر، ادفع ما تريد

Emdy مُنشَر تحت GPLv3. لا جدار دفع، لا تقييد، لا فترة تجربة. التطبيق مجاني للتنزيل والاستخدام إلى أجل غير مسمى.

Emdy أداة مساعدة. طلب حساب أو بيانات دفع قبل قراءة وثيقة بدا مقايضة خاطئة. الإيرادات تعتمد على الحجم والنوايا الحسنة.

التوزيع خارج App Store. التوصية الشفهية من المطورين هي القناة. المستخدمون غير التقنيين لا يبحثون عن قارئ. يسألون الشخص الذي أرسل لهم الملف. إذا عرف المطورون بوجود Emdy، يمكنهم التوصية به.

ما أخذتُه من هذا العمل

النطاق هو أصعب قرار تصميمي. كل طلب ميزة معقول بمعزل. تصفّح تفرّعي. تحرير Markdown. تصدير HTML. كل واحد يدفع المنتج بعيدًا عن نيّته الأصلية. أصعب عمل كان تقرير ما يُترك خارجًا.

الحزمة التقنية لم تقرّر الجودة. التحوّل من Swift إلى Electron بدا أمرًا كبيرًا في حينه. عند النظر للوراء، جودة Emdy جاءت من نظام التصميم والعمل على التفاصيل. أيٌّ من الحزمتين كان يمكن أن يُطلق هذا التطبيق.

البحث وفّر الوقت. البحث المكتبي والاستبيان القصير أخذا أيامًا قليلة. أبعداني عن بناء محرر (لم يطلبه أحد) وأكّدا أن النسخ كنص منسّق يستحق الأولوية.

المهندسون كانوا الجمهور الذي لم أتوقعه. بعد الإطلاق، جاء جزء كبير من الاستخدام من المطورين. لم أضعهم في أولوياتي البحثية لأنني افترضتُ أنهم سيفتحون ملفات .md في بيئة التطوير الخاصة بهم. اتضح أنهم فضّلوا قارئًا مخصصًا، وهذا يبدو منطقيًا عند النظر للوراء. هم يستقبلون Markdown أكثر من أي أحد.