Переделка Twitter — часть 1

Выглядит как Twitter. Говорит как Twitter. Должно быть, это Ghost Messenger.

Сегодня я начинаю специальную серию статей о создании альтернативного приложения для социальных сетей Ghost Messenger (вот его биография в Твиттере).

Я называю его ReMaking Twitter, но приложение не совсем то же самое. В частности, в области алгоритмов, которые будут питать его коммуникационные модели. Это просто быстрый способ сообщить, что по сути это приложение для социальных сетей.

Я начал работать над Ghost год назад на доменном имени semicolon.dev. Изначально он никогда не задумывался как отдельный мессенджер. Просто сайт для размещения технических статей и вообще для практики кодирования веб-сервера на Node.js.

Но как человек, который уже создавал платформы социальных сетей в прошлом (для развлечения и чтобы научиться кодить), многие идеи, которые сделали Ghost тем, чем он является сегодня, были замаринованы в течение десятилетия.

Минимально необходимые функции

Создавая приложение в той же нише, что и Twitter, вы, по сути, будете создавать тот же тип базовой технологии, потому что первая задача — создать набор минимально необходимых функций (MRF) — которые, по мнению пользователей, должны быть у вас, иначе они просто не будут даже рассматривать возможность дальнейшего использования вашей платформы.

Эта потребность существует независимо от типа приложения, которое вы создаете. У людей, как правило, высокие ожидания от современных приложений.

Плохой UX часто является причиной провала многих хороших идей. Люди не хотят гадать, где находятся те или иные функции. Они хотят, чтобы постинг был простым. Они хотят, чтобы все было быстро.

MVP vs MRFI Мне не нравится термин MVP, потому что нет ничего минимального в приложении, которое способно успешно работать. MRF — более реалистичный термин, потому что вы думаете о перечислении полного гранулированного набора функций.

Теперь это не так просто, как кажется. Потому что для создания MRF вам необходимо глубокое понимание потребностей в вашей продуктовой нише. Это требует наличия видения и страсти к проекту, основанной на позитивных намерениях по отношению к пользователям.

В отличие от этого, для создания MVP (а именно так это традиционно делается в наши дни) многие полагаются на отношение к своему приложению как к побочному проекту, подчиненному более важным вещам в жизни (просмотр любимого сериала Netflix, достойная работа в сфере технологий с полной занятостью, забота о детях и т.д.).

Timeline Flood & борьба с избыточным постингом

Мысленной искрой для написания этого поста послужила одна особенность, над которой я работал, и которую вы увидите как в Twitter, так и в Ghost.

Представьте себе пользователя, который только что опубликовал 10 твитов подряд.

В этом нет ничего плохого.

Но следствием этого является то, что он переполняет временную шкалу.

Это создает как минимум две проблемы:

  1. Скука. Аудитория временной шкалы начинает скучать, никто не хочет видеть 10 сообщений подряд от одного и того же пользователя.

  2. Больше — не всегда больше. Пользователь, разместивший сообщение, тоже не получает большой выгоды. Внимание распределяется на 10 сообщений, вместо того, чтобы высказать одну убедительную мысль в одном сообщении. И это выглядит как спам.

Решение проблемы наводнения временной шкалы одним и тем же пользователем

Почему этот пользователь должен получать видимость 10 или более сообщений в основной временной шкале?

Они не должны. Видимым должно быть только последнее сообщение. Остальная часть временной шкалы должна быть заполнена сообщениями всех остальных пользователей, чтобы быть справедливой. Но из-за хронологической природы временной шкалы это не так просто, как просто удалить все остальные сообщения того же пользователя. Потому что другие пользователи тоже могут писать твиты в промежутках между сообщениями этого пользователя. И этот особый случай использования должен быть сохранен.

Один из способов сделать это — читать только уникальные записи из коллекции твитов Mongo с помощью функции Mongo distinct(). Но не так просто использовать distinct() для очистки временной шкалы так, как это описано в предыдущем параграфе.

Трудно заставить distinct() работать таким образом, чтобы она возвращала только 1 сообщение от пользователя, который опубликовал 10 сообщений подряд, но сохраняла другие сообщения на временной шкале, если другие пользователи опубликовали твит в любое время между этими твитами.

Чтобы сделать это правильно, лучше использовать простой цикл forEach в JavaScript:

Я использую этот код для фильтрации временной шкалы и избавления ее от повторяющихся сообщений.

/* Get all tweets from database */
const tweets = await getTweets()
/* Create the actual list that will be displayed on timeline */
let final = []
let previousUsername = ""
tweets.forEach(tweet => {
  if (previousUsername !== tweet.username)
    final.push(tweet)
  previousUsername = tweet.username
})

/* At this point final[] should contain a list
   of tweets without copius repeats */
Вход в полноэкранный режим Выйти из полноэкранного режима

В основном логика такова: пропустить следующий твит, если предыдущий был опубликован тем же пользователем.

Я заметил забавный побочный эффект: Если кому-то другому удастся опубликовать сообщение между 10 сообщениями, то его сообщение будет помещено между двумя последними сообщениями пользователя, который опубликовал 10 сообщений подряд.

Получить Ghost Messenger

Помогите протестировать Ghost Messenger на его ранней стадии.

Вы можете стать одним из самых первых пользователей Ghost Messenger 🙂 .

Большинство имен пользователей еще доступны, так что успейте получить свое, пока это еще возможно.

Для установки откройте приложение в Safari на iPhone и добавьте его на домашний экран.

Ghost Messenger… во плоти.

Оцените статью
devanswers.ru
Добавить комментарий