Должны ли мы убивать функции, которые пользователи часто не используют, для повышения производительности?

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

Я очень скептически отношусь к этому изменению, так как лучше всего сортировать данные в длинных списках (наши списки могут достигать 100 элементов), но в то же время производительность (время загрузки) приложения очень важно для компании.

Любые предложения?

Примечания:

Благодаря kettch для этих вопросов:

Знают ли ваши пользователи, что столбцы сортируются? - Да в пользовательских тестах почти все пользователи заметили сортируемый заголовок

Каков средний размер набора данных? - Обычно вы получаете 50 строк на страницу, но для стандартного менеджера кампаний (наших целей) требуется только 4-5 элементов на страницу.

Почему пользователи, которые сортируют эту функцию? - У меня нет четкого ответа на этот вопрос, я бы сказал, что они пытаются найти неэффективные кампании, сортируя их по шагам или CTR

Является ли сетка данных настолько мучительно медленной, что пользователи никогда ее не используют? - На самом деле это не так быстро, но, по-видимому, функция сортировки вызывает проблемы в базе данных и создает несоответствие в данных.

Заметки разработчика для проблемы:

  • Проблема с получением данных в postgresql из-за количества вызовов, необходимых для обновления этих данных, просто для того, чтобы мы могли сортировать их, если менее 5% наших пользователей действительно используют это для сортировки.
  • Не будет масштабироваться навсегда так, как сейчас.

То, что мы выиграли бы, сделав это так, как мы планируем:

  • в режиме реального времени. Например, действительно в режиме реального времени. Каждый раз, когда вы обновляете страницу, вы увидите последнюю производительность (а не через 2 минуты после или что-то еще)
  • Лучшая производительность не только для списка, но и для всего продукта. Меньше «заморозить» в некоторых приложениях
  • Оптимизация затрат, потому что нам не нужно было вычислять ее каждые 2 минуты, хотя никто бы не видел данные (в ночное время и т. д.). Мы вычислили бы его только при необходимости

 введите описание изображения здесь>> </a> </p></div>
				<div class= gui-design business-application ux-integration heatmaps

98 голосов | спросил Deniz Erdal 3 Jpm1000000pmTue, 03 Jan 2017 16:27:59 +030017 2017, 16:27:59

18 ответов


84

Производительность важна, но даже более того, что ваши цели достигнуты.

Рассмотрим , какие пользователи используют функцию сортировки . Поскольку, например, может случиться так, что эти пользователи, хотя и немного, являются теми, кого вы заинтересованы в поддержке.

Я предлагаю тестирование A /B , чтобы узнать, как удаление сортировки влияет на ваши цели. Вы можете обнаружить, что хотите повысить функциональность поиска, но все равно сохраняете сортировку.

ответил Alvaro 3 Jpm1000000pmTue, 03 Jan 2017 16:34:34 +030017 2017, 16:34:34
200

Помимо того, что было сказано в других хороших ответах, у вас есть гораздо более фундаментальная проблема. Вы неправильно читаете свои данные.

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

Представьте, что у вас есть интернет-магазин. Стандартная карта нагрева отображает тонну щелчков по функциям, связанным с просмотром, просмотром комментариев и т. Д., И только очень мало кликов по кнопке «Оформить заказ». Это не означает, что никто не использует эту кнопку, это означает, что люди нажимают тонну других вещей во время посещения, а затем только размещают заказ один раз. И именно так вы хотите, чтобы они действовали! В вашем случае вполне возможно, что каждый из ваших пользователей использует сортировку, но только нужно сделать это один раз за посещение - и по-прежнему считать его чрезвычайно полезным для своей задачи. (Я не говорю, что это должно быть то, что происходит, но с вашими данными вы не можете это исключить).

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

Как только вы получили эту информацию, вы можете начать рассмотрение вопроса о том, следует ли удалить функцию, используемую несколькими посетителями, или нет. (Если вы обнаружите, что только 10% пользователей, когда-либо проводивших проверку в своем интернет-магазине, вы удалили бы кнопку «Оформить заказ»?)

ответил Rumi P. 4 Jpm1000000pmWed, 04 Jan 2017 18:08:20 +030017 2017, 18:08:20
40

Знают ли ваши пользователи, что столбцы сортируются?

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

Каков средний размер набора данных?

Если после поиска я получаю всю необходимую информацию на одном экране данных, я бы не склонялся к сортировке.

Почему пользователи, которые делают сортируют, используя эту функцию?

Это sort , связанный с предыдущим вопросом. Не всем пользователям нравится искать. Я видел, как пользователи просто берут данные по умолчанию и сортируют «n», прокручивая их путь к счастью.

Является ли сетка данных настолько мучительно медленной, что пользователи никогда ее не используют?

Возможно ли, что пользователям просто не нравится сортировка из-за проблем с производительностью? Как разработчик, занимающийся UX, я не уверен, что я покупаю производительность в качестве барьера. Если ваше приложение не выполняет огромные агрегации при каждом сортировке, нет никаких причин, по которым вы не можете агрегировать данные, а затем сортировать результат. Вы можете даже периодически предварительно вычислять агрегаты. Само присутствие рода не должно быть проблемой.

ответил kettch 3 Jpm1000000pmTue, 03 Jan 2017 18:29:27 +030017 2017, 18:29:27
24

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

Этот комментарий, который, вероятно, пришел от разработчиков, не является точным, если все сделано правильно. «функция сортировки, вызывающая проблемы в базе данных и создающая несоответствие данных». Этот комментарий заставил бы меня устать от них. Для меня это отговорка за то, что она ленива и не хочет улучшать ситуацию.

Я бы не удалял параметры, если они важны для страницы, поскольку их не так много, чтобы начать поиск. Я вижу только 3 фильтра, и это не должно быть значительным успехом.

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

ответил Micah Montoya 3 Jpm1000000pmTue, 03 Jan 2017 19:11:19 +030017 2017, 19:11:19
10

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

ответил Josh Olsen 3 Jpm1000000pmTue, 03 Jan 2017 19:14:48 +030017 2017, 19:14:48
10

Вы всегда должны быть extreme осторожны при удалении функции. Большинство компаний не очень хорошо понимают, почему их клиенты выбирают свою продукцию над конкурентами ». Всегда есть вероятность, что вы случайно удалите функцию убийцы и выйдете из бизнеса. Чтобы удалить функцию, у вас должна быть очень хорошая причина для бизнеса. Из вашего вопроса это не похоже на то, что у вас действительно есть причина business , чтобы удалить эту функцию. Итак, короткий ответ: не удаляйте его.

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

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

На стороне плюса, с вашего вопроса, кажется, что для удаления этой функции есть NO REASON WHATSOEVER .

  

То, что мы выиграли бы, сделав это так, как мы планируем:

в реальном времени. Например, действительно в режиме реального времени. Каждый раз, когда вы обновляете страницу, вы увидите последнюю производительность (а не через 2 минуты после или что-то еще)
Лучшая производительность не только для списка, но и для всего продукта. Нельзя «замораживать» часть приложений
Оптимизация затрат, потому что нам не нужно было вычислять ее каждые 2 минуты, хотя никто бы не видел данные (в ночное время или что-то еще). Мы вычислили бы его только при необходимости

Ничто из этого не имеет никакого отношения к сортировке или связано каким-либо образом. В частности, я хотел бы обратиться к «а не через 2 минуты после или как» и «потому что нам не нужно будет вычислять его каждые 2 минуты». Это очень сильно говорит о проблеме major с вашей архитектурой базы данных. Во-первых, вы должны never хранить вычисленные значения в БД, потому что тогда согласованность данных становится кошмаром. Так как вы также упоминали: «по-видимому, функция сортировки, вызывающая проблемы в базе данных и создающая расхождение в данных», я собираюсь выйти на конечность и сказать, что действительно вызывает несоответствие ваших данных, заключается в хранении сгенерированных /вычисленных значений в БД.

Но на самом деле гораздо хуже, чем , потому что для сортировки не должно быть POSSIBLE , чтобы вызвать несогласованность данных на бэкэнд. Сортировка выполняется как часть операторов select, которые обычно доступны только для чтения. Независимо от того, как вы сортируете результаты поиска, таблица, в которой вы получили результаты, не изменяется.

ответил industry7 6 Jam1000000amFri, 06 Jan 2017 00:28:21 +030017 2017, 00:28:21
4

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

По моему мнению, прирост производительности не будет таким большим, как трудности, которые он создаст для пользователей. Им будет лучше загружать 0,1 медленнее, но быстро узнать низко /высокопроизводительные кампании.

Кроме того, производительность может быть улучшена различными способами, которые непосредственно не влияют на удобство использования. Но это целая другая область.

ответил Kristiyan Lukanov 3 Jpm1000000pmTue, 03 Jan 2017 18:53:38 +030017 2017, 18:53:38
4

Для меня ключевой вопрос, когда вы решаете убить или перепроектировать существующую функцию, прост: какова будет чистая прибыль в юзабилити? Общее правило: если вы не видите выигрыш не менее 20% (по каким-либо метрикам (-ам) важно для вашего домена), вы, вероятно, не должны этого делать. 20% -ное число не имеет значения, важно то, что вы думаете о том, что это значит для вашего приложения, которое можно использовать, измерять текущую производительность пользователя по сравнению с этим определением, а затем измерять последствия предлагаемых изменений и решать, оправдывают ли доходы изменение.

Похоже, что изменение, которое вы создали, более полезно для разработчиков, чем для пользователя. Будучи профессионалом UX, я боролся с зубами и ногтями против . Даже если только 5% пользователей используют сортировку, это, безусловно, не делает ваше приложение менее удобным для других пользователей. Но вы можете поспорить, что вы серьезно повредите юзабилити на 5% с прямыми последствиями (сердитые обзоры в социальных сетях и приложениях, возможная потеря клиентов /доходов, увеличение стоимости поддержки и т. Д.), И для чего?

Работа вашего интерфейса - это решение проблем пользователей, а не упрощение работы вашего разработчика.

ответил Andy Rice 4 Jpm1000000pmWed, 04 Jan 2017 18:42:05 +030017 2017, 18:42:05
2

Сохраняйте интерфейс как есть, но попросите разработчиков переместить обработку сортировки на клиентскую сторону.

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

ответил Robyn 5 Jam1000000amThu, 05 Jan 2017 02:25:13 +030017 2017, 02:25:13
2

Прежде чем рассматривать возможность удаления функции (которая забирает ресурсы), подумайте о следующем:

  • Кто использует его? В зависимости от сортировки приложения может быть функция, которая использует только пользователей, и вырезать своих пользователей с помощью функции - это плохой ход. По моему опыту (и я уверен, что это относится ко многим другим разработчикам), опытные пользователи - это те, кто дает вам самые конструктивные отзывы о вашем продукте. Властные пользователи являются долгосрочными пользователями. Они не просто проверяют ваше приложение, а затем переходят к следующему. Это клиенты, которым вы хотите, чтобы ваша пользовательская база была переполнена. Если пользователь не удовлетворен вашим приложением, шансы на то, что он станет сильным пользователем, прошли через окно.

  • Является ли это непреднамеренно скрытой функцией? Возможно, используемый в настоящее время дизайн пользовательского интерфейса вашего приложения на самом деле не показывает пользователям, что сортировка даже возможна, поэтому большинство пользователей на самом деле не знать об этом и, следовательно, не использовать его. Выполнение чего-то в этом направлении может дать положительные результаты или, по крайней мере, дать вам более конкретную оценку использования этой функции. Если у приложения есть какой-то учебник или, по крайней мере, оверлей с полезной информацией о том, что к чему, попробуйте добавить информацию о сортировке где-нибудь (больше, если уже присутствует). Я часто удивляюсь, как многие пользователи пропускают очевидные (мне) вещи. Хорошее взаимодействие с пользователем начинается с обучения пользователя самым быстрым и простым способом, каким образом он может использовать ваш продукт. Иногда не найти определенную функцию может привести к тому, что пользователь сбросит ваше приложение и отправится к вашим конкурентам.

Что касается аспектов развития (поскольку я сам инженер-программист):

  

Проблема с получением данных в postgresql из-за количества вызовов   необходимо было обновить эти данные, просто чтобы мы могли их сортировать, если меньше   чем 5% наших пользователей на самом деле используют это для сортировки.

Если что-то редко используется и все же вводит регулярно возникающие накладные расходы, то что-то не так с тем, как работают ваши звонки. Если 5% ваших пользователей используют эту функцию, а не только в этом 5%, накладные расходы должны произойти.

  

Не будет масштабироваться навсегда, как сейчас.

Несколько вариантов здесь: применить сортировку по подмножествам, а затем объединить результаты (-> сортировать сортировку слияния), создать предварительно отсортированные представления (если данные не изменяются, часто вы можете предложить пользователю очень быстро отсортированную список, так как вы уже сделали это на сервере), установите ограничение на количество данных, которые можно сортировать (например, если вы обнаружили, что после 1000 записей сортировка приводит к слишком большому количеству сортировки служебных данных до 1000 записей -> , позволяя пользователю сортировать только выбранное подмножество, также является опцией) и т. д.

  

в режиме реального времени. Например, действительно в режиме реального времени. Каждый раз, когда вы обновляете страницу, вы увидите последнюю производительность (а не через 2 минуты после или что-то еще)

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

  

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

См. предыдущую цитату выше.

  

Оптимизация затрат, потому что нам не нужно было вычислять ее каждые 2 минуты, хотя никто бы не видел данные (в ночное время и т. д.). Мы вычислили бы его только при необходимости

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

Что мне кажется странным, так это то, что вы упоминаете, что ваши списки могут достигать даже 100 предметов. Позвольте мне сказать вам кое-что - 100 элементов в списке даже для приложения не так много. Я бы сказал, что ваши разработчики не сделали правильной работы, если сортировать список из 100 элементов (я полагаю, что каждый элемент не содержит мегабайт данных, но если да, то какие такие данные даже делают в мобильном приложении ?!) создает такую ​​большую проблему. Я ничего не знаю о технологии, которую вы используете (JS + HTML, Qt, Java и т. Д.), Но есть много готовых к использованию компонентов списка, которые оптимизированы для обработки огромного количества элементов. Возможно, ваши разработчики выбрали неправильные инструменты для работы?

ответил rbaleksandar 8 Jam1000000amSun, 08 Jan 2017 01:36:14 +030017 2017, 01:36:14
1

Нет, вы должны отметить удаление. Поскольку сортировка - важная функция, которую вы можете использовать в будущем с более изысканными критериями поиска. Вместо того, чтобы удалять ее, сделайте ее более подробной, вероятно, пользователь не получит критерии фильтрации, которые им нужны.

ответил Jasmin Javia 3 Jpm1000000pmTue, 03 Jan 2017 16:34:49 +030017 2017, 16:34:49
1

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

Во-вторых, доступны другие варианты. Разработчики не редко используют исправление «все или ничего», поскольку они не будут рассматривать пользователей как их основной показатель того, функционирует ли страница как ожидаемая.

Если существует проблема, указанная в первом абзаце, могут ли быть эффективны в улучшении способа загрузки данных или данных в кеше? Могло ли соединение данных быть более эффективным?

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

Если во время загрузки существует проблема, и время загрузки не может быть улучшено в фоновом режиме, вы можете разрешить пользователям отключать сортировку в своих предпочтениях с учетом снижения времени загрузки и производительности в качестве сладости, также информируя их они могут включить сортировку в любое время?

ответил DarrylGodden 3 Jpm1000000pmTue, 03 Jan 2017 17:33:38 +030017 2017, 17:33:38
1

Один, сортировка - это функция, которую пользователи будут воспринимать как должное. Поэтому ни один пользователь никогда не скажет вам, насколько велика эта функция сортировки - они будут сообщать вам и быть очень недовольны, если эта функция исчезнет.

Во-вторых, я был бы очень и очень осторожен, если разработчик заявит, что удаление некоторой функции сделает приложение более эффективным. (И у меня есть приложение в магазине приложений Apple, у которого нет проблем с сортировкой около 10 000 предметов по-разному на iPhone 4, что примерно в десять раз медленнее современного устройства, поэтому я бы спросил WTF, что эти парни делают, если сортировка замедляется их применение вниз).

ответил gnasher729 9 Jpm1000000pmMon, 09 Jan 2017 14:44:18 +030017 2017, 14:44:18
1

Хорошие ответы уже есть, но я не могу удержаться от добавления двух центов.

Проблема заключается в том, что процент пользователей, использующих функцию, не является точной метрикой важности или значения функции.

Этот вопрос не новичок в разработке программного обеспечения. Я думаю, что каждый бизнес сталкивается с такими решениями на том или ином уровне. Например, в предыдущей карьере я управлял магазином для велосипедов. Чтобы иметь возможность поддерживать клиентов со странными велосипедами и оборудованием, мне часто приходилось покупать инструменты и оборудование, которые, вероятно, никогда не получат достаточный доход для оплаты самих себя. Итак, скажем, есть дорогой инструмент, который, вероятно, никогда не заплатит за себя, возврат инвестиций, по крайней мере, в первую перестановку, ужасен. Должен ли я покупать его?

Ответ: «Это зависит». В магазине велосипедов проблема заключалась в том, что, если бы я не поддерживал достаточно широкую базу клиентов, они бы пошли куда-то еще, что было лучше оборудовано, и как только у них были отношения с другим магазином велосипедов, они, скорее всего, отправились туда - даже для легкой, высокой отдачи от инвестиций. Если вы всегда можете решить проблемы с клиентами, они, скорее всего, придут к вам в первую очередь. Они также с большей вероятностью рекомендуют вам друзей.

Когда вы решаете возврат инвестиций в программную функцию, применяются аналогичные мысли.

  • Когда потенциальный пользователь оценивает ваш инструмент, они могут сравнивать списки функций, даже если они никогда не используют какую-либо особенность, которую они могут утешить, зная, что она там, если они когда-либо понадобится.
  • Предположим, что компания оценивает использование вашего инструмента. 99% их пользователей не нуждаются в функции X, но ОДИН человек делает, и они не могут жить без него. Они выберут инструмент, предоставляющий функцию X, хотя статистика количества пользователей X может показаться незначительной.

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

ответил Spacemoose 12 Jam1000000amThu, 12 Jan 2017 11:40:40 +030017 2017, 11:40:40
0

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

ответил Gray Roberts 4 Jpm1000000pmWed, 04 Jan 2017 14:23:02 +030017 2017, 14:23:02
0

Есть много хороших ответов.

В случае, если нет адекватных, как насчет другого подхода:

Переименуйте текущую версию. Вместо текущей версии поставьте версию, которая не имеет сортировки, но у нее есть кнопка «Разрешить сортировку». Если они нажмут на них, они перейдут к старой дорогостоящей версии, иначе они будут использовать новую дешевую версию.

ответил Loren Pechtel 5 Jam1000000amThu, 05 Jan 2017 07:58:25 +030017 2017, 07:58:25
0

Тепловые карты очень ограничены. Я беспорядочно нажимаю на вещи все время, а в половину времени это не очень полезно. Лучше посмотреть на использование функций пользователем . То есть: какой из наших пользователей использует сортировку? И еще лучше изучить , почему они используют сортировку?

Возьмите сортировку на Amazon. Это самосвал. Люди поиск , а результаты поиска - все мякины, поэтому они пытаются сортировать , чтобы отделить пшеницу от мякины. И он никогда не работает , потому что там столько мякины! И это то, над чем Amazon должен выглядеть очень тяжело. Фильтрация, многоуровневая сортировка, что угодно.

Итак, лучший вопрос: , когда люди сортируют, что они на самом деле после? И как нам лучше доставить это?

Я полностью согласен, вы не должны делать это на стороне базы данных. Механизм базы данных - ценный ресурс. Программисты не должны бросать тяжелые задания в базу данных просто потому, что их легче закодировать.

Еще лучше, сделайте сортировку по запросу прямо на ПК пользователя. Это экономит время транзакции в сети . Классическая ошибка дизайна заключается в проверке на гигабитной сети в офисе, в то время как у вашего пользователя iPad 2G падает на EDGE сотовый с потерей пакетов на 11%. Таким образом, сетевая активность имеет большое значение для удобства использования. Если вы используете телефон для использования в отчетах об использовании, сделайте фоновое действие не критически важным.

ответил Harper 7 Jpm1000000pmSat, 07 Jan 2017 23:39:45 +030017 2017, 23:39:45
0

Я согласен, что вы не должны удалять эту функцию. Я видел это раньше, когда какой-то менеджер удаляет функцию, потому что он думает, что никто ее не использует. Пользователи начинают жаловаться ... поэтому функция вернулась, но с некоторыми новыми ошибками, потому что кодеры, изменяющие другие функции, опустили эти функции «никто не использует».

ответил user3719694 5 AMpThu, 05 Apr 2018 01:22:24 +030022Thursday 2018, 01:22:24

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132