В нашем веке новые технологии приходят на смену старым так быстро, что порой становится даже с жутко, когда понимаешь, что за последние пару недель, когда ты не читал новости случилось столько нового и интересного. И последнее время можно охарактеризовать как время изменения представлений. Причем совершенно в различных сферах. Да и чего только не поменялось за последнее время.
В свою очередь я хотел бы поговорить о так называемом моменте «Loading». Под этим знакомым словом конечно подразумеваю принцип в целом. Все мы прекрасно помним текст вида «Соединение...», «Загрузка» или что чаще «Loading». И сейчас в огромном количестве различных приложений и устройств мы видим это. Но что же в мире? В мире твориться революция дизайна, стиля и эргономики. Устройства становятся производительнее, интернет всё быстрее, дизайн всё проще. И только вот недавно стал мучить вопрос: «От чего же мы до сих пор коннектимся да загружаемся?»
Если уж прямо, то от чего же в нашем веке сверхбыстрой техники и интернета мы до сих пор вынуждены наблюдать процесс соединения? Возможно стоит уходить от этого? Любой процесс требующий долгого или указывающий на сам факт «соединения» «или загрузки» должно признать устаревшим. Этот момент так прочно осел в умах разработчиков, что этого зачастую не замечают. Да что там говорить, я сам не прочь показать этот момент пользователю.
Пришло время отойти и от этого пережитка. Вы включаете устройство, которое не подключается к интернету, оно уже соединено! Для вас оно не выходило даже, для вас не существует ожидания от соединения есть только непроизводительная система или канал связи не способный удовлетворить минимальные запросы. Разумеется процесс как таковой может присутствовать но внешне это должно происходить незаметно или опережая саму потребность. Необходимо всецело отойти от принципа ожидания пользователем чего-либо. Если нет возможности закачать все данные по столь узкому каналу, тогда требуется построить процесс так, чтобы пользователь уже сейчас мог получить ответ системы позволяющий ему сформировать первое представление об этих данных. Как, возможно не лучший, пример можно привести сравнение с форматом GIF, когда подгрузка может осуществляться постепенно, и первое возможно слабое впечатление пользователь уже может оценить.
К слову проблема не упирается только в интернет или сетевые приложения, этот момент можно проследить в очень многих видах приложений работающих с приличным объемом данных или требующих значительного процессорного времени. Зачастую всё взаимодействие сводиться к «запрос-ответ». Так для серьезных обработок или закачек, оно превращается в «запрос-пауза-ответ». Этот стремительный мир не может жить в паузе. Тенденция современного мира требует неотлагательных манипуляций.
К слову не всё так плохо. Много чего уже достигнуто, пожалуй не минуя грабли. Так в хороший пример можно привести сам процесс просмотра видеороликов на таком портале как youtube. Для контраста рассматриваемой проблемы вспомните, как закачивали весь фильм целиком, чтобы только взглянуть моменты.
Места где существует данная проблема можно перечислять долго, но пока это не сформируется в идею, которой будут придерживаться большинство, ситуация будет оставаться ещё долго в старом русле.
Итак, какие основные моменты следует определить?
- 1. Интерфейс программ не должен быть жестко зависим от процесса
Так нажав кнопу длительной обработки, пользователь не должен наблюдать как программа «подвисла», или она запрещает манипулировать её параметрами. Не должно быть подергиваний интерфейса или появление графических артефактов. Программа должна работать так же плавно и отвечать на запросы пользователя. В идеале даже предлагать некоторые изменения подхватывать на лету для уже запущенного процесса обработки, скажем.
- 2. Передача данных должна формироваться из принципа «1 к 1000» или «1 к 1 секунде».
Смысл принципа «1 к 1000» в том, чтобы одну тысячную передаваемой информации пользователь уже смог воспринять и возможно даже произвести какие-то манипуляции. Так же принцип «1 к 1 секунде», где информация передается гарантированно секунду и всё, что успело передаться пользователь смог узреть.
- 3. Контроллер процессов должен иметь приоритет на уровне архитектуры.
Как становится понятно из двух предыдущих моментов, процесс контролирующий другие процессы должен иметь свой гарантированный остаток процессорного времени, и эту гарантию должна нести уже архитектура, а не исполнение.
Не внося в список, но желая видеть, хотел бы упомянуть «горячую» перезагрузку, для основных устройств пользователя.
Да возможно многие скажут, что это всё идеализм, или, что в некоторых задачах не требуется, и в чем-то я бы согласился. Но описанным выше предлагаю не менять только себя или свои программы, предлагаю менять подход, саму основу.
Думаю вот оно время, когда изменяют компьютеры для людей, а не людей для компьютеров.
