All streams
Search
Write a publication
Pull to refresh
44
0
qbique @qbique

User

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

Тач-интерфейсы, кстати, тоже подчиняются этим правилам
слишком категорично :) человек за 14 лет не сильно изменился, а правила просты как дверь, не вижу причин, почему они не работают сегодня
там это где? :)
Круто! А как включить m_look и прицел? ;)
Спасибо, Кэп!
Конечно, всем стоит постоянно учится чему-то, иначе деградация. Мне просто не понятны стенания верстальщиков по поводу сложности работы. Вёрстка сложного макета — небольшой вызов и хороший результат — повод для гордости. Работа дизайнера тоже не лишена сложностей. Попробуйте с таким раздутым эго сдать макет, пройдя 5-10-15 итераций, пока клиент не будет удовлетворён. Это тоже не просто.
Прям не могу промолчать :)

Нечёткие границы — это банально проблемы с квалификацией. Если визуальщик не видит, что он не попадает в пиксель или ему это не кажется существенным, то это тупо отсутствие правильного воспитания :) Впрочем, как и макет, где нет ни одного layer set. Хотя были времена, когда все так рисовали, даже очень крутые парни :) Просто фотошоп тогда папок для слоёв не умел делать.

Есть масса пожеланий здравых, но есть и весьма спорные утверждения. Я сам и рисовал и верстал, попробую посмотреть на ситуацию под другим углом. Я вот читаю статью и комментарии про то, что «дизайнер должен и то и это», но по факту работы, верстальщику приходится работать в граф. редакторе добрые 2/3 времени, в то время как дизайнер про код разве что только слышал. Так может есть смысл Вове просто немного прокачать свои технические навыки? Ведь да, можно тыкнуть пипеткой, какие проблемы? Если вы думаете, что кто-то заметит разницу в тоне, то можно взять базовый цвет текста, посмотреть на прозрачность и сделать прямоугольный блок небольшого размера с нужным цветом и прозрачностью, тыкнуть пипеткой и получить точный цвет. Отношение к теням убило просто :) Глубокие красивые тени научились реализовывать задолго до появляения box-shadow, и резиновые и какие угодно. Даже MS Windows научился рендерить более менее приличные тени под своими окнами. Призыв с ними бороться в 21 веке звучит не очень убедительно. Вон Дима 6 слоёв перевёл для придания нужной глубины и вообще старался. А кому-то лень «заморачиваться»? Даже если требуется 100% соотвествие, то нарубить блок с тенью вообще не составляет труда. Я их столько нарубил, не счесть :)

Ещё хотелось бы по поводу эффектов наложения. Дизайнер ведь тоже немного програмист, поэтому стремится оптимизировать свою работу. Куда проще бросить дефолтный чёрно-белый градиент поверх цветной плашки и накрутить всякого. Получится вполне себе блок, который можно перекрасить в 2 клика мышки. При другом подходе, пришлось бы подбирать массу других цветов только для изменения базового цвета. И такие решения по своему красивы =) А вот если бы Вова просто позвал к себе Диму и на пальцах показал ему свою сложность, то велика вероятность, что дизайнер бы просто показал, как без потерь сконвертировать в нужный результат. А ещё есть вероятность, что увидев проблему своими глазами, Владимир тоже стал бы немного лучше. А у парней, судя по всему, несгибаемое самомнение, полное нежелание учиться и проблемы с коммуникацией :) Но я отвлёкся. Моя мысль в том, что если бы Вова не думал о себе всякое и просто выучил пару фокусов, то мир стал бы лучше.
Я прям вижу, как он скачет в красном балахоне и призывно кричит «Грядёт Open Source, братья и сёстры, алилуйя! Освободим датацентры от дьявольской проприетарщины! » и в такт ему подвывает негритянский хор =)
Да, но реальность такова, что большенство жирных компаний предпочитают держать ресурсы под рукой.
Ваш случай не говорит о том, что это панацея. Вы думаете, американцам интересны сотрудники в офисе исключительно потому, что «У всех этих Цукербергов и Шмидтов в головах такие же устаревшие бюрократические заборы»? Я уверен, что успешный бизнесмен, настоящий человек-калькулятор, плевать хотел на заборы. Его интересует максимальная прибыль и минимальные потери. Повторюсь ещё раз, но для бизнеса чел на удалёнке — потенциальный головняк, связанный с низкой предсказуемостью. контролем и прочим.
Именно так, да. Благодоря этому уменьшается влияние человеческого фактора. Ну, на тот случай если шибко важный разработчик Николай решит, что он слишком хорошо и помашет компании ручкой. Для монстра это не будет проблемой, ведь взаимозаменяемых ресурсов предостаточно. А что будет в небольшой, компании если ведущий специалист по какой-либо причине не сможет выполнять свои обязанности? Образуется огромная дыра и куча геморроя.
Вы сравниваете небольшую продуктовую компанию с энтерпрайз-монстром?
Почему я, сидя в своей маленькой деревне, не могу работать над каким-нибудь Microsoft Office?

Очень наивно, да. Вы в команде работали? Ну, когда нужно быстро и дружно решать каки-либо проблемы. Человек на удалёнке — постоянный источник рисков для бизнеса. Сотрудник в офисе > удалённо работающего спеца.
Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.


Это первое, что расстраивает при первом знакомстве. И я, удручённый, допилил комплексную отправку модели и всех её ассоциаций обратно на сервер. И, о чудо, теперь можно загрузить сложную структуру и править её в реальном времени! Отзывчивость UI будет, уууххх! Мы так и делали, а пустя некоторое время, я понял, что выстрелил себе в ногу :)

Например, есть некая модель пользователя, а у него есть список контактов и куча других ассоциаций. Редактируем один контакт, и отправляем пользователя обратно на сервер обновиться. Сервер в ответ возвращает новую структуру, которая уже никак не связана с записью, которая сейчас всё ещё открыта на редактирование. Ведь, фактически, это json, который пропустили через Reader, который, в свою очередь, выдал набор инстансов модели. Если тупо взять и положить их обратно в коллекцию, то получится, что в редакторе находится ссылка на устаревшую запись. Самый проблемный случай — когда мы добавляем несколько записей, те отправляем модели без идентификатора, чтобы сервер знал, что это записи на добавление. Если ничего не сделать, то при повторном нажатии на заветный Save, сервер может решить, что вы добавляете ещё одну запись в контакты, а возможно и удаляете только что созданый (ведь его нет в коллекции, верно?) Чтобы решить проблему, прошёл через муки реализации синхронизации данных…

В любом случае, Ext рекомендует использовать отдельные сервисы для CRUD операций над коллекциями (Ext.data.Store, если быть точным) и тогда проблем не будет. Загрузили данные в коллекцию, вытащили запись, обновили, store.sync() и горя не будет. Я был молод, горяч и не прислушался, теперь сильно сожалею :) Вообще, в ExtJS все решения достаточно логичны, чтобы убедиться, стоит только самому реализовать недостающую функциональность. Зачастую, становится понятно, что вот они, эти грабли, которые обошли ребята из сенчи :)
Вы сейчас описали весь ужас, который испытывает разработчик, когда с jq переходит на ext =) Поработайте пол года, а лучше год, потом расскажите как оно. Лично я сам так же первое время мучался, когда ломался мозг в попытках принять новые абстракции и концепции. Но когда понимаешь и принимаешь, то приходит просветление и разрабатывать становится просто и быстро. Из всех недостатков, которые вы перечислили, только ошибки в коде являются проблемой. Всё остальное — от непонимания.
> в обычной жизни американцы очень редко используют грубые слова
ну да ну да, вы правы, если речь идёт о официальных публичных выступлениях или о сферических американцах.
рекомендую ознакомится — www.youtube.com/watch?v=2JfMCBh1sJQ — «shit», «fuck», «motherfucking truck» и тд и тп. обратите внимание, публика реагирует нормально. что вы там говорите про обычную жизнь американцев?
«длинна» GET запроса — 2,048 символов. если вы привысили лимит — значит что-то не так. ну ещё и идеологическая подоплёка, тащить данные через POST — не достаточно православно :)
> хватит запрашивать данные GET'ом:
это почему же? GET как раз и предназначен для получения данных, использование POST в данном случае неоправдано.
я слышал, что на западе это чуть ли не законодательно регулируется, в том плане что могут быть юридические проблемы, если accessibility не на должном уровне
Как опытный дизайнер, я всегда настороженно отношусь к коментариям «сделали бы нормальный дизайн». Новый дизайн раблера объективно хорош. Чисто, грамотно, эстетично. Ваши примеры возможно и удобнее (вопрос привычки? вкуса?), но визуально в разы проигрывают рамблеру. Та же лента.ру по сравнению с Р. просто привет из 90х, а у нас 21 век кстати. Так же я знаю, что люди, которые делали дизайн для Р прошли все круги ада, но не ударили лицом в грязь. Конечно, обладатель высокого вкуса легко бросает «Почему бы не заплатить за нормальный дизайн?», ведь вам всё равно, как там было на самом деле, правда?

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

Зачем тогда спрашивать?
Как минимум, чтобы узнать собеседника поближе.

Еще очень удивляет — почему дизайн не сделать резиновым? Он же у вас из четких блоков.
Сайт — отзывчивый, ловко подстаивается под размер экрана. Есть ограничение по максимальной ширине, что вполне оправдано.

Суть ваших притензий не ясна. Спасибо!

Information

Rating
Does not participate
Date of birth
Registered
Activity