Даже это дофига, если делать что-то в фотошопе (да хотя бы слайсы проставлять для верстки). А в реальности, думаю, будет больше 100ms. Тут же вопрос не только в скорости канала, а в пинге (задержке) в обе стороны. А спутник - это в принципе большая задержка.
Но в принципе если работаете и ощущения лагов при быстром наборе текста или стирании нет, то хорошо. Фиг знает, я в шеле при 200ms уже еле работаю.

в ФШ работать в удаленной среде проектирование - нонсенс, естественно работаешь со своего компа и грузишь .psd
А посколь не дизайнер, основная работа в текстовых редакторах, плюс контроль и тестирование результатов

12 лет инета - портят любого, особенно ежли не статья или иная офлайн-заготовка

ничего они о работодателе не говорят, кстати он здесь лукавит насчет того, что плевать, "с кем вы работали" ))

О, это было исключительно в контексте бахвальства "работал с удаленными и программерами и дизайнерами."

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

У нас нет типовых задач. У нас нет штамповки. Мы беремся за крупные проекты и вылизываем их до блеска. По-этому, я не могу сказать "вот макет, верстай; сверстал? молодец, возьми с полочки 200 баксов".

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

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

То же и при разработке общей архитектуры - технический директор не ставит задачи фронт-енду, он с ними их обсуждает. Причем часто это происходит в виде "а как же нам это сделать... черт (10 минут молчания) .. о! давай так-то".

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

Конечно, рано или поздно у нас накапливается всякая рутина, которую можно отдать удаленно. Но сейчас я ищу не таких людей. Я ищу тех, с кем можно будет обсуждать проекты, и кто в дальнейщем имеет шанс стать тим-лидом фронт-енда, и вот он уже будет передавать всякую рутину удаленщикам, их обучать, приручать и все такое.

А людей с повышенным гонором а-ля "да я руководил интернет-департаментом" лично я - не люблю. А высказываю свое отношение прямо, без окивоков и страха "ох, что же подумают про мою вакансию". Уж извините, кому от этого внезапно стало плохо.

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

В вашем случае, вы нецелесообразно тратите время команды проекта и нервы верстальщика, котрый после 100 раз переделывания одного и того же через месяц попросит себя уволить ;)

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

Нам - не пофигу. Вот в этом и отличие.

Сверстанный протитип поменять много легче, чем полностью сверстанный и выверенный сайт. В итоге наша схема наоборот экономит кучу времени и нервов.

Для студий, у которых "дизайнер всегда прав", конечно, ваш вариант больше подходит.

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

Для чего его верстать-то?

Ок, mail.ru студия где "дизайнер всегда прав" )

Целеориентированное проектирование дает ответ - что должен интерфейс делать. Но он не дает ответ - удобно ли в итоге получилось, кнопка должна быть справа или слева и т.п. Это можно предположить на опыте, но не всегда и не 100%, а выяснить можно лишь получив рабочий прототип.

Ибо он уже близок к конечному результату. Может вас смущает слово прототип - у нас их три стадии (или больше). От бумаги до результата близкого к итоговому. Это уже можно верстать и даже программировать.

А дизайнер пусть рисует свои иконки, рюшечки, кнопочки и тому подобное вплоть до общей сетки сайта, куда пойдет интерфейс. При достаточном профессионализме верстальщика переделать прототип для получения готового сайта совершенно не равнозначно "все переверстать".

Mail.ru где-то отличилась удобными интерфейсами? ;)

Все вы так, на словах потрепаться - крутые:
а как до дела доходит - пустышки. :-/ :

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

Не буду спорить, но если бы действительно было все так хорошо, то все не было бы так плохо. Боюсь, там слишком много маркетологов.

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

Верно, ибо это очень накладно, т.к. разработчики всегда забиты на 200%

Конечно если цифры показывают что что-то не так, то либо эксперимент сворачивается либо вносятся какие-то мелкие изменения на процент пользователей

В общем, мне не очень интересно, как построено проектирование интерфейсов в mail.ru. Ибо их интерфейсы говорят сами за себя, а значит там особо нечему учиться. Да и вы многое прояснили. Это у многих компаний крупных так. Тот же гугл в общем целом не блещет. Фасад еще ничего, а копнешь поглубже, в какие-нибудь настройки...

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

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

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

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

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

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

А заказчик платит за верстку прототипа?

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

Я правильно понимаю что прототип это внутрненняя разработка, которая не демонистрируется заказчику?

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