Mango та обмін повідомленнями – у нас проблема

Windows Phone 7 Mango сьогодні розповсюдили кілька представників преси, і кожен огляд був позитивним. Проте одна проблема, яку я бачу, полягає в тому, що я не повністю задоволений однією ідеєю, з якою я спочатку думав, що повністю підійшов. Стаття є відповіддю на Ельдара Муртазіна та рецензії mobile-review на коментарі Джо Бельфіоре про систему iMessage і те, як iMessage вирвав багато ідей з гарячих рук Microsoft. Перейдіть за посиланням, щоб побачити можливі рішення та проблеми, які я бачу в повідомленнях Mango, які, можливо, потрібно змінити.

Тож, переглядаючи Twitter учора вранці, я перше, що я бачу, це твіт із мобільного огляду про Проблема з SMS в Mango де коментарі здаються справді цікавими. Не буду втомлювати всіх подробицями, але суть статті можна звести до різних пунктів, взятих із самої статті. Зокрема:

Мене трохи образило те, що Microsoft вважає iMessage копією месенджера, який ми бачимо в Windows Phone 7 Mango. У них є щось спільне, але я не думаю, що їх можна назвати ідентичними.
Spillikins #123. Сучасні мобільні клієнти обміну повідомленнями – підхід Microsoft проти Apple

У Windows Phone 7 Mango користувач нарешті став центром спілкування – не важливо, якою програмою ви користуєтеся, ви будете отримувати повідомлення від будь-якої програми миттєвого обміну повідомленнями, як-от Facebook Chat або SMS, і всі ваші повідомлення відображатимуться як чат.
Spillikins #123. Сучасні мобільні клієнти обміну повідомленнями – підхід Microsoft проти Apple

Але в чому головна відмінність цих послуг від SMS? Різниця в тому, що доставка SMS надається оператором, і ви завжди можете отримати звіт про статус повідомлення. Хоча доставка повідомлень у сучасних клієнтах миттєвих повідомлень НЕ гарантується – ми можемо лише сподіватися, що вона пройде. Це величезна різниця, яка дозволяє мені сказати, що концепція обміну повідомленнями, яка використовується в Microsoft Windows Phone 7, наразі має один, але значний недолік – вона поєднує служби гарантованої доставки повідомлень (SMS) з імовірними послугами.
Spillikins #123. Сучасні мобільні клієнти обміну повідомленнями – підхід Microsoft проти Apple

Щоб бути відвертим на мить, я почав скубати себе за волосся, міркуючи про аргументи тут: оскільки SMS та інші послуги поєднані, і користувачі не мають уявлення про те, надіслано повідомлення чи ні, фундаментальна різниця між ними полягає в повідомлення. Я знаю, що раніше Ельдар сумнівався у своїх думках, але це так дурний аргументу. А потім, чесно кажучи, став критично ставитися до статті. І я прийшов до висновку, що, хоча Ельдар робить дуже цікавий момент, він абсолютно не враховує. Зосередженість на системі сповіщень може бути одним із таких незначний проблеми в інтегрованій схемі, запропонованій Microsoft. І через деякий час я виявив ще кілька проблем, які слід було вирішувати негайно. Зрештою, я сподіваюся, що ці міркування потрібно сприймати серйозно та впроваджувати, перш ніж користувачі отримають Mango. Або, принаймні, Аполлон. Давайте почнемо.

Пам’ятаєте, коли було анонсовано Mango, і однією з ключових функцій був новий спосіб взаємодії людей один з одним – через MSN, Facebook та через SMS, створюючи інтегрований досвід? Якщо ні, давайте швидко подивимося на це в дії:

Подивившись на цю функцію, користувач знайомиться з «потоками» (людьми, з якими було зв’язано) на одному екрані. Гортання праворуч показує будь-які онлайн-контакти і, звісно, ​​останні. І хоча сторінка контактів не є тим аспектом, який повинен бути ключовим, ключове значення має починатися з потоків та інтерфейсу.

Перейшовши прямо в інтерфейс, користувач показував повідомлення на відповідних платформах – MSN, Facebook чи SMS. Але всі повідомлення відображаються на одному екрані. Тепер це може бути гарною ідеєю, але давайте дамо кілька нагадувань про те, чому ця ідея дійсно може бути нудною, і рішення проблеми:

1. Засмічений
Сам інтерфейс захаращений, і хоча я погоджуюся з Елдаром у тому, що групування систем може бути поганою ідеєю, я не будую це на сповіщеннях, тому що все, що я бачив, система сповіщень про те, чи є онлайнове повідомлення чи ні. відправлено на місці. Однак, з естетичної точки зору, макет sms для консолідації всіх повідомлень може бути захаращеним і заплутаним. Зрозуміло, є чудовий тег, який вказує, куди користувач надсилає повідомлення у вашому списку контактів, що є чудовою ідеєю, але загалом він виглядає майже неорганізованим з усіма службами разом.

2. Розмір повідомлень
Будьмо справжніми. Повідомлення користувачів. Багато. Я помітив (як і деякі інші тут а також тут. Якщо навіть у NoDo після 1,000 повідомлень виникла помилка обміну повідомленнями, давайте подумаємо, що станеться, якщо буде розмова в чаті; які легко можуть складатися з тисяч і тисяч рядків повідомлень. Я бачив затримку та відчував затримку й миготіння вікна SMS-чату під час власного використання безлічі пристроїв, тому я не можу стверджувати, що пристрій відкритий лише для один пристрій. Я думаю, що це серйозна системна помилка.

3. Повідомлення
Ельдар робить кілька цікавих пропозицій щодо методу сповіщення, який використовував Windows Phone, але лише подряпав поверхню. Я скеровую свою стурбованість на фактичну схему сповіщень, яка використовується. Коли користувач отримує сповіщення про повідомлення, оперативна плитка з’являється (як у будь-якому SMS), а коли користувач вибирає її, користувач переходить до ланцюжків. Будь-яке нове повідомлення світиться текст під іменем користувача. Це воно. Тож дайте мені побачити, чи я зрозумію це, якщо зможу. Mango об’єднує сповіщення про повідомлення подібно до NoDo та попередньої збірки, і очікує, що це буде від користувачів точно звідки надходить SMS. На основі лише виділених слів. Ніякі додаткові індикації не вказують користувачеві, чи це SMS, миттєве повідомлення у Facebook чи навіть повідомлення MSN.

А потім, думаючи про безпосередні проблеми, я згадую кампанію Microsoft щодо Windows Phone – вона повинна позбавити користувачів від їхніх телефонів і дати нам яскравий і чарівний новий дизайн інтерфейсу, який не бачили, і як би зламати бар’єр. Зрозуміло, що Microsoft зламала форму з ідеєю об’єднання повідомлень у формат, схожий на центр, але можна зробити краще, враховуючи деякі проблеми, які я бачу з точки зору естетики, взаємодії з користувачем та досвіду користувача. Отже, яке рішення для створення кращого досвіду? Дивно, але це не так революційно, як можна подумати, але все ж може бути еволюційним.

Почнемо з живої плитки. Поточна плитка Mango Live показує, що повідомлення отримано, але що, якби щось подібне сталося:

Мій фотошоп відстойний, але ви бачите, що я говорю?

З живої плитки користувач точно знає, звідки надходять повідомлення. Звичайно, через розмір і кепське вміння Photoshop, розмір сповіщення завеликий для всіх 3. Тож, можливо, для значків щось на кшталт 20×20 і шрифт для сповіщень від 12 до 14 пунктів? Я думаю, що таку схему можна було б розширити і на систему сповіщень блокування екрана, щоб також продовжити кампанію «вхід, виходь» (чи це Windows Phone врятує нас від нашого телефону, чесно кажучи, я вже не пам’ятаю).

Продовжуючи роботу з системою сповіщень, як ми дізнаємося, який контакт надіслав нам нове SMS, а який – повідомлення у Facebook чи MSN? Як не дивно, це також можна легко вирішити, як можна побачити нижче:

Розміщення піктограм може бути на початку повідомлення або в кінці повідомлення в режимі перегляду ланцюжка.

Порівняно з «поточною» системою, ланцюжок вказує, куди користувачі надіслали їм повідомлення – з facebook, sms чи MSN. Головне, на що я розраховую, це – ймовірність того, що користувачі SMS і facebook/MSN надішлють одне й те саме повідомлення, невелика, якщо це не надзвичайний випадок. Недоліком було б, якби було два повідомлення з двох різних систем обміну повідомленнями та простору. Але в ідеалі розмір значків можна змінити до чогось правдоподібного, і, звичайно, це вирішило б проблему. Але малоймовірно, що хтось приверне вашу увагу обома способами, якщо це не надзвичайна ситуація або якщо вони не психічні.

Поки що є режим перегляду потоків та живої плитки, що вказує на розташування контактів для обміну повідомленнями. Це не заплутано, і користувачі мають чудове уявлення, яка послуга використовується, особливо якщо користувачі ввійшли всі послуг. Але як щодо інтерфейсу обміну повідомленнями? Я сказав, що це було дуже незграбно і неорганізовано, тому що повідомлення просто мають тег. Що якби для кожного режиму обміну повідомленнями були окремі сторінки? Наприклад, користувач вибирає ім’я/номер контакту і переходить до 3 вікон залежно від того, звідки користувачу було надіслано повідомлення. Один для SMS, один для Facebook і один для MSN, якщо контакт використовує всі три служби. Звучить дивно? Ось кілька фотографічних доказів:

Вуаля! Безладу зникло, центр обміну повідомленнями виглядає набагато більше, і звідки надійшло повідомлення, дуже мало плутанини. Проблема з надмірною кількістю інформації в одному вікні усувається на користь більш раціонального та організованого підходу. Нарешті, дозвольте покращити збирання сміття або консолідований перегляд повідомлень, щоб все було швидко. Дайте користувачам можливість контролювати історію SMS, щоб більше не було затримок.

Але як щодо твердження Ельдара? Як легко вирішити цю проблему! В ідеалі за цієї парадигми проблема вирішується сама собою. Але що робити, якщо кінцевий користувач досі не має уявлення про те, чи надсилається онлайн-повідомлення? Це легко! Прозорий ефект для видимого ефекту, якщо повідомлення надіслано. Візуально користувач знає, надіслано повідомлення чи ні. Хоча твердження Елдара дивні (враховуючи, що користувачі не мають уявлення про те, чи надсилаються коли-небудь їхні SMS-повідомлення в чаті чи ні), насправді недостатньо сказати, що ідея обміну повідомленнями Apple унікальна. Або гарний, або навіть досить інший сам по собі. Це не. Однак у Microsoft є деякі недоліки з моєї особистої точки зору, які можна легко вирішити в Mango або майбутніх ітераціях Microsoft. Якщо вся ідея — це центр обміну повідомленнями, зробіть його більше схожим на центр! Просто як це!