|
Фев
01
|
Подход «Getting Real» при создании веб-приложений
 (1 голоса, средний балл: 5 из 5) Loading ... |
Думаю сегодня мало кто не знает (или хотя бы не слышал) про такую компанию, как 37signals.
А для тех кто не знает — это компания из Чикаго, которая прославилась на весь мир своими продуктами (BaseCamp, Ta-Da list, Campfire, Ruby On Rails и другими) и политикой создания своих продуктов.
На сегодняшний день их проектами пользуются более 1 миллиона человек по всему миру.
В чем же их успех, спросите вы. Ответ довольно простой на самом деле.
Ознакомившись с материалом их книги (которую кстати рекомендую к прочтению) стает понятно, что компания пропагандирует принцип «KISS» (Keep It Simple, Stupid! — что дословно означает «делай проще, дурень!»), который они «обозвали» «Getting Real».
В современном мире, где человек утопает в потоках информации, где программы содержат кучу разного функционала ( которым большинство пользователей даже не пользуется) , где каждый день нужно делать все быстрее, чем вчера — человека так и тянет сделать все проще, упростить себе жизнь.
Ведь именно поэтому мы «homo sapiens», что мы мыслим. Действительно ли так нужны большинство «наворотов», которые присутствуют сегодня? Спросите себя, насколько полноценно вы используете функционал той программы, которой пользуетесь каждый день (музыкальный плеер, Office, почтовый клиент, браузер да и что угодно)?
Иногда я сам задаю себе вопрос — а нужен ли мне весь тот функционал, который мне доступен? Делает ли он меня счастливее? Делает ли он мою работу удобнее и комфортнее? И ответ чаще всего — нет. Меня отвлекают перегруженные интерфейсы, множество кнопочек, ненужных мне сервисов и твиков. Они тратят мое время и отвлекают от первоначальной цели использования данных программ.
Со временем конечно ко всему можно привыкнуть, но зачем заставлять себя привыкать? Разве нельзя изначально сделать проще и только то, что требуется? Неужели нужно перегружать интерфейс всем пользователям ради удобства N% других пользователей (которые просто тащатся от кучи фенечек и кнопочек)? Почему не дать возможность выбора пользователю — какой функционал ему нужен, а какой нет? Зачем мне эти десятки пунктов, когда я пользуюсь допустим только одним 98% своего времени работы с данной программой?
Вопросов слишком много, чтобы можно было ответить на них одним махом. К счастью, есть люди, которые тоже тяготеют к минимизации и оптимизации работы пользователей.
Именно принцип минимизации или «Getting Real» и пропагандирует 37signals, создавая свои веб-проекты. Они делают только самые необходимые вещи в интерфейсе и ничего лишнего. Благодаря этому они и стали настолько известны.
Несколько простых примеров работы их принципа на примере продукта Campfire:
«Почему вы не показываете общее число людей в комнате чата?»
Ответ: Это не имеет значения. Все имена внесены в список, так что вы знаете, кто есть в чате, но, какая разница, если это 12 или 16 человек? Если это не меняет ваше поведение, то это не имеет значения.
Хорошо если были бы эти функции? Безусловно. Но являются они сутью? Будут ли они востребованы? Нет. И вот почему мы их опустили. Лучшие проектировщики и лучшие программисты — не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, — это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения.
«Почему время показывается только каждые 5 минут? Почему нет времени в каждой линии чата?»
Ответ: Это не имеет значения. Как часто вам нужно отслеживать беседу с секундной или даже с минутной точностью? Конечно, не 95% времени. 5 минут вполне достаточно, поскольку какие-то меньшие промежутки времени — не имеют значения.
Не имеет значения. Действительно же — не имеет. Ведь важна суть, а не лишние навороты, правда?
Вообще у меня сложилось впечатление, что человечество периодически проходит период, когда что-то, что им создавалось — стает перегруженным и тогда появляется человек (или несколько человек или компания), который показывает, что вещи могут быть проще, чем они есть на сегодняшний день.
Самым простым примером может послужить мода на минимализм в дизайне, которая появилась, как противовес перегруженным графикой дизайнам веб-сайтов. Есть и другие примеры подобных вещей.
Как известно — история идет по спирали и данный пример только подтверждает эту теорию.
В целом, как мне кажется, 37signals не изобрели ничего нового, просто появились в правильном месте, в правильное время и продемонстрировали то, в чем нуждался рынок. Но они напомнили о том, о чем стоит помнить всегда, а именно — не стоит все усложнять.
Естественно это не все, что лежит в принципе «Getting Real», а только малая его часть. Тем читателям, которые заинтересовались данным принципом (возможно есть и такие) — я бы рекомендовал прочесть книгу от 37signals.
Она не является технической, поэтому легко читается даже без специальных знаний и будет полезна даже тем, кто не занят в сфере IT — принцип легко проекцируется на любую область деятельности человека.
Вас тоже утомили перегруженные интерфейсы и ненужные фичи? Тогда мы уже идем к вам >:-)
01.02.2009 в 20:35
Что-что, а точное время каждого сообщения в чате имеет значение.
01.02.2009 в 21:28
wicharek
Какое? Насколько это важно для рабочего процесса?
02.02.2009 в 01:40
Для меня самое важно в “Getting Real” — это подход “меньше проектировать, больше делать”. А то я на практике убедился, как все тормозит, если проектировать слишком долго
02.02.2009 в 12:50
дословно - “не усложняй” = “поддерживай простоту”. делать наде не проще, а просто.
02.02.2009 в 13:40
а какой подход вы используете, вставляя полноразмерную картинку, а не тамбнейл, и заставляя браузер ресайзить ее ? современные дизайнеры настолько ленивы или безголовы ?
02.02.2009 в 16:42
zwitter:
Метод грубой силы. В админке перестало работать создание превьюшек, а мне пока нет времени это починить.
P.S. Я не дизайнер совсем, не понимаю, почему люди часто думают, что я дизайнер.
02.02.2009 в 18:39
«Getting Real» книга просто гениальная, и как все гениальное - очень простая
Для разработчика или дизайнера веб приложений это должно быть настольной библией. Когда я ее читал я постоянно удивлялся как это у авторов получается написать или то что я думаю или что то новое, но с чем я согласен на 100%. В ней рассказывается не просто теория, а принципы которые можно (и нужно) тут же применять на практике.
Хочу отметить один из основных принципов описанный в книге, но который тяжелее всего принимается. Это “делать МЕНЬШЕ чем конкуренты”. Собственно это следует из принципа не делать лишнего. Это буквально значит что если у вашего конкурента 10 функций то вы должны сделать 9. Тут все понятно - но для меня не просто подавить в себе желание добавить еще какую-нибудь новую функцию, и приходиться постоянно себя останавливать
Кстати поэтому с basecamp уже не у кого не получается эффективно конкурировать - из него просто уже нечего выкинуть.
06.02.2009 в 06:56
Делать функционал надо основываясь не на количестве фич у конкурентов, а на пожеланиях пользователей. Все-таки для пользователей работаем в первую очередь и т.д.
07.02.2009 в 15:02
Интересный совет. Вот теперь мне очень любопытно узнать каким-же образом у вас происходит рабочий процесс, если у вас есть пожелания пользователей уже на этапе планирования проекта?
Лично у меня рабочий процесс происходит примерно так: возникновение идеи, изучение рынка и потенциальных конкурентов, планирование, реализация, запуск, пользователи, пожелания пользователей…
Так вот я говорил о том что на этапе планирования (еще до начала какой либо реализации) важно ограничиться только самым необходимым. Это залог того что процесс реализации будет быстрым, появятся пользователи со своими пожеланиями и вот тогда уже можно будет прислушиваться к ним и вносить улучшения.
Кстати о том как именно стоит слушать пожелания пользователей тоже хорошо описывается в этой книге
07.02.2009 в 19:41
У нас все-таки, разные сферы, деятельности, я работаю в аутсорсинге, главный пользователь — это заказчик. Единственный свой проект, разрабатываемый не на заказ я делал в основном для себя. Свои проекты разрабатывать труднее, но и намного интереснее. Вы можете рассказать подробнее о своей практике разработки?
13.02.2009 в 21:56
Мы отказались от campfire только из за отсутствия индикатора печати в чате. Когда идет конференция очень неудобно когда смешивается поток, а так каждый может уступить дорогу тому кто ведет беседу в данный момент.
А в общем были очень довольны, мелочь но работодателям эта мелочь показалась не очень то и мелочью.