نگران نباش خواننده عزیز، زیرا من قصد ندارم رابط های برنامه ‌نویسی اپلیکیشن (API) در سیستم‌های فایلی محبوبت را از شما بگیرم. من در اینجا می‌خواهم در رابطه با "تجربه" کاربری صحبت کنم و نه چگونگی ساختن این تجربه. مدت زمان زیادی است که سیستم‌ های فایلی بخش قابل اعتماد بیشتر کامپیوتر ها بوده اند، و همین روال احتمالاً در سیستم‌های عامل برای سال‌های متمادی نیز ادامه خواهد یافت. ولی چندین گرایش نوظهور در رابط‌های کاربری نشان دهنده این است که علیرغم انعطاف کدهای اساسی و ساختار اطلاعاتی  آن،  مدل اساسی سیستم فایلی، ناتوان از تأمین کامل نیازهای کاربران جدید است.

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

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

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

واحدهای تکی و مجزا

قبل از ظهور اینترنت، چاپ تنها راه نشان دادن واقعی و قانونی بودن بیشتر اطلاعات بود. هدف کامپیوترها این بود که WYSIWYG identity mapping میان محتوا و برونشو را نشان دهند. در رابط‌های کاربری جدید اطلاعات اغلب به طرق مختلفی نشان داده می‌شوند و واحدها را می‌توان برای کاربران مختلف و عملیات مختلف و با روش‌ های مختلف ادغام کرد. به عنوان مثال کاربران موبایل ممکن است که حتی از طریق شناخت صدایشان از طریق تلفن، بخواهند ایمیل را بر روی دستگاه‌های PDA خود دریافت کنند. برای انجام این کار نشان دادن اطلاعات باید به طور قابل ملاحظه‌ای خلاصه‌تر از نمایش اطلاعات بر روی نمایشگر یک کامپیوتر مرکزی باشد.

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

برخی از راه‌های بهبود تجربه کاربری مشکلات قبلی را پیچیده ‌تر می‌کنند، مثلاً عکس ‌های GIF و JPEG ممکن است به خودی خود در سیستم فایلی وجود نداشته باشند ولی می‌توان در صورت درخواست کاربر آنها را از یک شمایل پایه ای بازتولید کرد که این کار با استفاده از روش‌هایی همچون فشرده سازی، اتلاف و color-map depth که بسته به پهنای باند موجود و ملاحظات دیگر تعیین می‌شود، انجام پذیر است. به عنوان مثال اگر شما یک صفحه وب سایت را در دفتر کارتان با استفاده از یک لینک مستقیم اینترنتی دانلود کنید عکس‌ها به صورت بزرگ، زیبا و رنگ 24-bit به دستتان می‌رسند اما اگر همان صفحه را در خانه و با سرعت اینترنت کمتر دانلود کنید، صفحه را با تصاویر کوچک‌ تر، بی‌کیفیت‌ تر و سیاه و سفید خواهید دید.

مشکلاتی که در حین آف‌لاین بودن رخ می‌دهند  

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

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

بخش به بخش

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

درختان مجزا

سیستم‌های فایلی بر سلسله مراتب دقیق و واضحی از دایرکتوری ها و و زیرمجموعه‌های آن‌ها بنا نهاده شده است. اما برای کاربران همین اطلاعات یکسان، معمولاً طبقه‌بندی‌های متعددی دارند. لوگوی یک کمپانی ممکن است روی صفحات متعدد یک وب سایت به چشم بخورد و بنابراین متعلق به واحد اطلاعاتی چندین صفحه در دایرکتوری سرور است. من هنگام ارائه سخنرانی ‌هایم (با مجموعه‌ای کوچک از فایل‌ها) معمولاً از اسلاید که شامل تصاویر، صفحات وب سایت و دیگر طراحی‌ هائی که مشغول به کار بر روی آنها هستم استفاده می‌کنم. بنابراین یک عکس به خصوص ممکن است هم به عنوان بخشی از پروژه توسعه  "کتابچه راهنما" و هم به عنوان بخشی از پروژه سخنرانی "عبارت کلیدی سنگاپور" طبقه بندی شود. در هر یک از موارد اگر من یکی از واحدهای اطلاعاتی را تغییر دهم می‌خواهم که تمام واحدهای اطلاعاتی شبیه به آن نیز تغییر کنند. این اتفاق حتی با تغییر دادن ظاهر نیز بایستی رخ دهد. (مثلاً بزرگ‌ تر کردن 400 درصدی یک اسلاید یا کوچک‌ کردن آن). در اصل موضوع فرقی نمی‌کند زیرا همان اطلاعات ولی با ظاهری متفاوت هستند. فراموش نکنید که WYSIWYG رو به افول و ارائه هر چه پربارتر رو به شکوفائی است.

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

اسامی فایل

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

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

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