این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

یک رویکرد غیر پاسخگو برای ساخت برنامه های وب بین دستگاهی

Boris Smus

پرسش های رسانه ای عالی هستند، اما…

پرسش‌های رسانه‌ای عالی هستند، موهبتی برای توسعه‌دهندگان وب‌سایت که می‌خواهند تغییرات کوچکی در شیوه نامه خود ایجاد کنند تا تجربه بهتری را برای کاربران دستگاه‌هایی با اندازه‌های مختلف ارائه دهند. پرس و جوهای رسانه ای اساساً به شما امکان می دهند CSS سایت خود را بسته به اندازه صفحه شخصی سازی کنید. قبل از اینکه وارد این مقاله شوید، درباره طراحی واکنشگرا بیشتر بیاموزید و نمونه‌های خوب استفاده از درخواست‌های رسانه را در اینجا بررسی کنید: mediaqueri.es .

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

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

برنامه های وب به چیزی بیش از درخواست های رسانه ای نیاز دارند

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

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

چه کلاس های دستگاهی را هدف قرار می دهید؟

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

انواع دستگاه ها. — انواع دستگاه ها ( منبع ).

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

دو انتهای افراطی برای طیف رویکردها وجود دارد:

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

در اینجا یک مبادله اساسی وجود دارد: هرچه دسته‌بندی دستگاه‌های بیشتری داشته باشید، تجربه کاربری بهتری را می‌توانید ارائه دهید، اما طراحی، پیاده‌سازی و نگهداری کار بیشتری نیاز دارد.

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

یک راه حل بالقوه

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

صفحه نمایش کوچک + لمسی (بیشتر گوشی)
صفحه نمایش بزرگ + لمسی (بیشتر تبلت)
صفحه نمایش بزرگ + صفحه کلید / ماوس (بیشتر دسکتاپ / لپ تاپ)

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

نمونه هایی از برنامه های وب خاص فاکتور فرم

نمونه‌های زیادی از ویژگی‌های وب وجود دارد که نسخه‌های کاملاً متفاوتی را برای فاکتورهای فرم مختلف ارائه می‌کنند. جستجوی گوگل این کار را انجام می دهد، مانند فیس بوک. ملاحظات مربوط به این مورد شامل عملکرد (واکشی دارایی ها، رندر صفحات) و تجربه کاربری عمومی تر است.

در دنیای برنامه‌های بومی، بسیاری از توسعه‌دهندگان تصمیم می‌گیرند تا تجربه خود را با کلاس دستگاه تنظیم کنند. به عنوان مثال، Flipboard برای iPad دارای رابط کاربری بسیار متفاوتی در مقایسه با Flipboard در آیفون است. نسخه تبلت برای استفاده دو دستی و چرخاندن افقی بهینه شده است در حالی که نسخه تلفن برای تعامل تک دستی و چرخش عمودی در نظر گرفته شده است. بسیاری دیگر از برنامه‌های iOS نسخه‌های مختلف تلفن و تبلت را نیز ارائه می‌کنند، مانند Things (فهرست کارها) و Showyou (ویدئوی اجتماعی) که در زیر مشخص شده‌اند:

سفارشی سازی UI قابل توجه برای تلفن و تبلت.

رویکرد شماره 1: تشخیص سمت سرور

در سرور، ما درک بسیار محدودتری از دستگاهی که با آن سر و کار داریم داریم. احتمالاً مفیدترین سرنخ موجود رشته user agent است که در هر درخواست از طریق سربرگ User-Agent ارائه می شود. به همین دلیل، همان رویکرد sniffing UA در اینجا کار خواهد کرد. در واقع، پروژه‌های DeviceAtlas و WURFL این کار را قبلا انجام می‌دهند (و اطلاعات بیشتری در مورد دستگاه ارائه می‌دهند).

متأسفانه هر کدام از اینها چالش های خاص خود را دارند. WURFL بسیار بزرگ است، حاوی 20 مگابایت XML است که به طور بالقوه برای هر درخواست، هزینه های زیادی را در سمت سرور متحمل می شود. پروژه هایی وجود دارند که XML را به دلایل عملکردی تقسیم می کنند. DeviceAtlas منبع باز نیست و برای استفاده به مجوز پولی نیاز دارد.

جایگزین های ساده تر و رایگان نیز وجود دارد، مانند پروژه Detect Mobile Browsers . البته اشکال این است که تشخیص دستگاه ناگزیر از جامعیت کمتری برخوردار خواهد بود. همچنین، فقط بین دستگاه‌های تلفن همراه و غیر همراه تمایز قائل می‌شود و فقط از طریق مجموعه‌ای از ترفندهای موقت، پشتیبانی محدود از تبلت را ارائه می‌کند.

رویکرد شماره 2: تشخیص سمت مشتری

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

باید در جایی خط بکشیم تا دستگاه های لمسی کوچک و بزرگ را تشخیص دهیم. در مورد قاب‌های لبه‌ای مانند گلکسی نوت 5 اینچی چطور؟ گرافیک زیر مجموعه‌ای از دستگاه‌های محبوب Android و iOS را نشان می‌دهد که روی هم قرار گرفته‌اند (با وضوح صفحه‌نمایش مربوطه). ستاره نشان می‌دهد که دستگاه با تراکم دو برابری عرضه می‌شود یا می‌تواند عرضه شود. اگرچه تراکم پیکسل ممکن است دو برابر شود، CSS همچنان همان اندازه ها را گزارش می دهد.

کنار گذاشتن سریع پیکسل ها در CSS: پیکسل های CSS در وب تلفن همراه با پیکسل های صفحه نمایش یکسان نیستند . دستگاه‌های رتینا iOS عمل دوبرابر کردن تراکم پیکسلی را معرفی کردند (مثلاً iPhone 3GS در مقابل 4، iPad 2 در مقابل 3). UA های رتینا موبایل سافاری همچنان همان عرض دستگاه را گزارش می کنند تا از شکستن وب جلوگیری شود. همانطور که سایر دستگاه ها (به عنوان مثال اندروید) نمایشگرهایی با وضوح بالاتر دارند، همان ترفند پهنای دستگاه را انجام می دهند.

با این حال، پیچیدگی این تصمیم اهمیت در نظر گرفتن هر دو حالت پرتره و منظره است. ما نمی‌خواهیم هر بار که دستگاه را تغییر می‌دهیم صفحه را مجدداً بارگیری کنیم یا اسکریپت‌های اضافی را بارگیری کنیم، اگرچه ممکن است بخواهیم صفحه را به گونه‌ای متفاوت ارائه کنیم.

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

با تنظیم آستانه روی 650px ، آیفون، گلکسی نکسوس را به‌عنوان لمس کوچک و iPad، گلکسی تب را به‌عنوان «تبلت» طبقه‌بندی می‌کنیم. گلکسی نوت آندروژن در این مورد به عنوان "تلفن" طبقه بندی می شود و طرح بندی تلفن را دریافت می کند.

و بنابراین، یک استراتژی معقول ممکن است به این صورت باشد:

if (hasTouch) {
  if (isSmall) {
    device = PHONE;
  } else {
    device = TABLET;
  }
} else {
  device = DESKTOP;
}

نمونه حداقلی از رویکرد تشخیص ویژگی را در عمل مشاهده کنید.

روش جایگزین در اینجا استفاده از sniffing UA برای تشخیص نوع دستگاه است. اساساً شما مجموعه ای از اکتشافی ها را ایجاد می کنید و آنها را با navigator.userAgent کاربر خود مطابقت می دهید. کد شبه چیزی شبیه به این است:

var ua = navigator.userAgent;
for (var re in RULES) {
  if (ua.match(re)) {
    device = RULES[re];
    return;
  }
}

نمونه ای از رویکرد تشخیص UA را در عمل مشاهده کنید.

یادداشتی در مورد بارگیری سمت مشتری

اگر در سرور خود شناسایی UA را انجام می‌دهید، می‌توانید تصمیم بگیرید که چه CSS، جاوا اسکریپت و DOM در هنگام دریافت درخواست جدید ارائه شود. با این حال، اگر تشخیص سمت مشتری را انجام می دهید، وضعیت پیچیده تر است. شما چندین گزینه دارید:

به یک URL خاص برای نوع دستگاه که حاوی نسخه این نوع دستگاه است، هدایت شوید.
دارایی های نوع خاص دستگاه را به صورت پویا بارگیری کنید.

روش اول ساده است و نیاز به تغییر مسیری مانند window.location.href = '/tablet' دارد. با این حال، اکنون اطلاعات مربوط به این نوع دستگاه به مکان اضافه شده است، بنابراین ممکن است بخواهید از History API برای پاک کردن URL خود استفاده کنید. متأسفانه این رویکرد شامل تغییر مسیر است که می تواند کند باشد، به خصوص در دستگاه های تلفن همراه.

روش دوم برای پیاده سازی کمی پیچیده تر است. برای بارگیری پویا CSS و JS به مکانیزمی نیاز دارید و (بسته به مرورگر)، ممکن است نتوانید کارهایی مانند سفارشی کردن <meta viewport> را انجام دهید. همچنین، از آنجایی که هیچ تغییر مسیری وجود ندارد، شما با HTML اصلی که ارائه شده است گیر کرده اید. البته، می‌توانید آن را با جاوا اسکریپت دستکاری کنید، اما بسته به برنامه شما، ممکن است کند و/یا بی‌ظرافت باشد.

تصمیم گیری مشتری یا سرور

اینها مبادلات بین رویکردها هستند:

مشتری حرفه ای :

اثبات آینده بیشتر از آنجایی که بر اساس اندازه / قابلیت های صفحه نمایش به جای UA است.
بدون نیاز به به روز رسانی مداوم لیست UA.

سرور حرفه ای :

کنترل کامل از چه نسخه ای برای ارائه به چه دستگاه هایی.
عملکرد بهتر: بدون نیاز به تغییر مسیر مشتری یا بارگذاری پویا.

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

معرفی device.js

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

ایده این است که نشانه گذاری مناسب برای موتورهای جستجو ( لینک rel=alternate ) را در بالای <head> خود ارائه دهید که نشان می دهد کدام نسخه از سایت خود را می خواهید ارائه دهید.

<link rel="alternate" href="http://foo.com" id="desktop"
    media="only screen and (touch-enabled: 0)">

در مرحله بعد، می‌توانید شناسایی UA سمت سرور را انجام دهید و تغییر مسیر نسخه را به تنهایی انجام دهید، یا از اسکریپت device.js برای انجام تغییر مسیر سمت مشتری مبتنی بر ویژگی استفاده کنید.

برای اطلاعات بیشتر، به صفحه پروژه device.js و همچنین یک برنامه جعلی که از device.js برای تغییر مسیر سمت مشتری استفاده می کند، مراجعه کنید.

توصیه: MVC با نماهای خاص فرم فاکتور

تا به حال احتمالاً به این فکر می کنید که من به شما می گویم سه برنامه کاملاً مجزا بسازید، یکی برای هر نوع دستگاه. نه! اشتراک کد کلید است.

امیدواریم از یک چارچوب MVC مانند مانند Backbone، Ember و غیره استفاده کرده باشید. اگر قبلاً استفاده کرده اید، با اصل جداسازی نگرانی ها آشنا هستید، به ویژه اینکه رابط کاربری (لایه مشاهده) شما باید از منطق شما جدا شود. لایه مدل). اگر این برای شما جدید است، با برخی از این منابع در MVC و MVC در جاوا اسکریپت شروع کنید.

داستان بین دستگاهی به خوبی در چارچوب MVC موجود شما قرار می گیرد. شما به راحتی می توانید نماهای خود را به فایل های جداگانه منتقل کنید و یک نمای سفارشی برای هر نوع دستگاه ایجاد کنید. سپس می توانید همان کد را به همه دستگاه ها، به جز لایه view، ارائه دهید.

پروژه شما ممکن است ساختار زیر را داشته باشد (البته، شما مختار هستید که ساختاری را انتخاب کنید که بسته به برنامه شما بیشترین معنا را دارد):

models/ (مدل های مشترک) item.js item-collection.js

controllers/ (shared controller) item-controller.js

نسخه/ (چیزهای خاص دستگاه) تبلت/ دسکتاپ/ تلفن/ (کد مخصوص تلفن) style.css index.html views/ item.js item-list.js

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

هنگامی که ابزار ساخت مورد علاقه خود را اجرا کردید، همه جاوا اسکریپت و CSS خود را برای بارگیری سریعتر به یک فایل متصل و کوچک می‌کنید و HTML تولیدی شما چیزی شبیه به زیر است (برای تلفن، با استفاده از device.js):

<!doctype html>
<head>
  <title>Mobile Web Rocks! (Phone Edition)</title>

  <!-- Every version of your webapp should include a list of all
        versions. -->
  <link rel="alternate" href="http://foo.com" id="desktop"
      media="only screen and (touch-enabled: 0)">
  <link rel="alternate" href="http://m.foo.com" id="phone"
      media="only screen and (max-device-width: 650px)">
  <link rel="alternate" href="http://tablet.foo.com" id="tablet"
      media="only screen and (min-device-width: 650px)">

  <!-- Viewport is very important, since it affects results of media
        query matching. -->
  <meta name="viewport" content="width=device-width">

  <!-- Include device.js in each version for redirection. -->
  <script src="device.js"></script>

  <link rel="style" href="phone.min.css">
</head>
<body>
  <script src="phone.min.js"></script>
</body>

توجه داشته باشید که پرس و جوی رسانه ای (touch-enabled: 0) غیر استاندارد است (فقط در فایرفاکس پشت پیشوند فروشنده moz اجرا می شود)، اما به درستی (به لطف Modernizr.touch ) توسط device.js مدیریت می شود.

لغو نسخه

تشخیص دستگاه گاهی اوقات ممکن است اشتباه انجام شود، و در برخی موارد، یک کاربر ممکن است ترجیح دهد به چیدمان تبلت در تلفن خود نگاه کند (شاید از گلکسی نوت استفاده می کند)، بنابراین مهم است که به کاربران خود حق انتخاب نسخه سایت خود را بدهید. برای استفاده در صورتی که بخواهند به صورت دستی لغو کنند.

روش معمول این است که از نسخه موبایل خود پیوندی به نسخه دسکتاپ ارائه دهید. پیاده سازی این به اندازه کافی آسان است، اما device.js از این عملکرد با پارامتر device GET پشتیبانی می کند.

نتیجه گیری

به طور خلاصه، هنگام ساخت رابط‌های کاربری تک صفحه‌ای بین دستگاه‌ها، که به خوبی در دنیای طراحی واکنش‌گرا جا نمی‌شوند، این کار را انجام دهید:

مجموعه‌ای از کلاس‌های دستگاه را برای پشتیبانی و معیارهایی برای طبقه‌بندی دستگاه‌ها به کلاس‌ها انتخاب کنید.
برنامه MVC خود را با جداسازی شدید نگرانی‌ها، جدا کردن نماها از بقیه پایگاه کد بسازید.
از device.js برای تشخیص کلاس دستگاه سمت سرویس گیرنده استفاده کنید.
وقتی آماده شدید، اسکریپت و شیوه نامه خود را در یکی از هر کلاس در هر دستگاه بسته بندی کنید.
اگر عملکرد تغییر مسیر سمت کلاینت مشکل است، device.js را رها کنید و به شناسایی UA-sideside بروید.