Comments on: О вёрстке, холиворах и реалиях http://blog.nundesign.com/design/2008/04/css-good/ О дизайне и веб-дизайнерах Thu, 20 Nov 2008 05:51:39 +0000 http://wordpress.org/?v=2.5.1 By: NunDesign http://blog.nundesign.com/design/2008/04/css-good/#comment-6345 NunDesign Wed, 14 May 2008 11:03:18 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6345 Офисное дизайнерское: склоки и подставы [...] на вёрстку присылаются сюда, на Украину. Про различные недоговорённости и проблемы с вёрсткой я уже писала неоднократно, но сейчас разговор именно о [...] Офисное дизайнерское: склоки и подставы
[...] на вёрстку присылаются сюда, на Украину. Про различные недоговорённости и проблемы с вёрсткой я уже писала неоднократно, но сейчас разговор именно о [...]

]]> By: xzirrow http://blog.nundesign.com/design/2008/04/css-good/#comment-6206 xzirrow Sun, 04 May 2008 11:46:03 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6206 Прочитал - аж прослезился, насколько же до боли знакомо. Верстаем одно, потом в процессе хаки (и не только CSS) под контент. На самом деле спасибо за откровенность. Прочитал - аж прослезился, насколько же до боли знакомо. Верстаем одно, потом в процессе хаки (и не только CSS) под контент. На самом деле спасибо за откровенность.

]]> By: Zigzag http://blog.nundesign.com/design/2008/04/css-good/#comment-6177 Zigzag Fri, 02 May 2008 05:46:10 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6177 эээ... ни одного для дотнета =) эээ… ни одного для дотнета =)

]]> By: Anton Naumov http://blog.nundesign.com/design/2008/04/css-good/#comment-6170 Anton Naumov Thu, 01 May 2008 16:42:40 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6170 да я ведь не к тому, что Agile замордовал. просто так бывает. Waterfall проще и более прогнозируем для подрядчика, для заказчика немножко нервно заплатить за N-человекочасов, и получить результат только через это самое N часов / M человек. а вдруг не выгорит? потому и Agile. а где Agile, там и ваши проблемы. они на самом деле не только ваши, они общие. и тут я не случайно говорил про профессиональных ПМов. задача ПМа в Agile уметь грамотно обосновать для заказчика, когда пришло время рефакторинга. а оно приходит всегда. ибо эволюционное прототипирование. и это как-раз ваш случай, когда нужно время на рефактринг верстки и стилистики макета. я не прав? а остальное, это скорее ответ на цитату. сорри, занесло :) да я ведь не к тому, что Agile замордовал. просто так бывает. Waterfall проще и более прогнозируем для подрядчика, для заказчика немножко нервно заплатить за N-человекочасов, и получить результат только через это самое N часов / M человек. а вдруг не выгорит? потому и Agile. а где Agile, там и ваши проблемы. они на самом деле не только ваши, они общие. и тут я не случайно говорил про профессиональных ПМов. задача ПМа в Agile уметь грамотно обосновать для заказчика, когда пришло время рефакторинга. а оно приходит всегда. ибо эволюционное прототипирование. и это как-раз ваш случай, когда нужно время на рефактринг верстки и стилистики макета. я не прав?
а остальное, это скорее ответ на цитату. сорри, занесло :)

]]> By: Fenrir http://blog.nundesign.com/design/2008/04/css-good/#comment-6167 Fenrir Thu, 01 May 2008 10:57:19 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6167 ...а потом смотришь на страницу, в код которой заглядывать уже страшно, с такой <em>гордостью</em>. Просто потому, что через год, после неоднократной смены смены всего и вся у ей внутре, она <em>не разваливается</em>. Семантика ради самой семантики - да, не нужно по большому счету. Если на эту страницу никогда и ни при каких условиях не зайдет слепой, какая разница, как она читается? Но если сайт сделан специально для них? Или хотя бы в частности! А провокация... Вот честно... Не люблю табличные макеты. Мне очень трудно отлавливать в них баги при изменении сетки. У меня начинается нервный тик при виде colspan'ов и необходимости "вот тут колонку добавить, а тут убрать". Готовые контролы с точки зрения верстальщика - зло :) Но ситуация может поменяться на контрол "своими силами" только тогда, когда он станет злом и для программистов. По описанию функциональности .NET решений, вам это не грозит... …а потом смотришь на страницу, в код которой заглядывать уже страшно, с такой гордостью. Просто потому, что через год, после неоднократной смены смены всего и вся у ей внутре, она не разваливается.

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

А провокация… Вот честно… Не люблю табличные макеты. Мне очень трудно отлавливать в них баги при изменении сетки. У меня начинается нервный тик при виде colspan’ов и необходимости “вот тут колонку добавить, а тут убрать”.

Готовые контролы с точки зрения верстальщика - зло :) Но ситуация может поменяться на контрол “своими силами” только тогда, когда он станет злом и для программистов. По описанию функциональности .NET решений, вам это не грозит…

]]> By: nundesign http://blog.nundesign.com/design/2008/04/css-good/#comment-6165 nundesign Thu, 01 May 2008 09:23:05 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6165 Паш, я, кажется, знаю, почему не видишь логики. Ты как много верстал макеты для дотнетовских проектов? Если много, то все ли стандартные контролы ваши программеры писали с нуля сами, или же брали уже готовые гриды (таблицы с "расширенной функционаьностью"), деревья и прочие? А про редактор. Я же ж говорю - такое было требование заказчика. Сначала спорили, обосновывали свою точку зрения, потом махнули рукой. Саппорт-то всё равно на нас остался :) а это деньги. Поэтому поправить очередной "шедевр" форматирования ихней секретарши - не проблема. Впрочем это именно тот проект, который пришёл к нам на редизайн. Может, мы пересмотрим вопрос с этим визуальным редактором. Паш, я, кажется, знаю, почему не видишь логики. Ты как много верстал макеты для дотнетовских проектов? Если много, то все ли стандартные контролы ваши программеры писали с нуля сами, или же брали уже готовые гриды (таблицы с “расширенной функционаьностью”), деревья и прочие?

А про редактор. Я же ж говорю - такое было требование заказчика. Сначала спорили, обосновывали свою точку зрения, потом махнули рукой. Саппорт-то всё равно на нас остался :) а это деньги. Поэтому поправить очередной “шедевр” форматирования ихней секретарши - не проблема.
Впрочем это именно тот проект, который пришёл к нам на редизайн. Может, мы пересмотрим вопрос с этим визуальным редактором.

]]> By: nundesign http://blog.nundesign.com/design/2008/04/css-good/#comment-6164 nundesign Thu, 01 May 2008 09:21:15 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6164 Ах, Антон. Да не проблема же конечно же. Если есть макет, который можно проанализировать на предмет разметки главных контейнеров и элементов и написать красивую таблицу стилей. Я же пишу не о том, что вот у нас была дивная вёрстка, а потом Agile режим нас замордовал и случилась табличная вёрстка, нет. Просто стерильная и логичная вёрстка стала не стерильной и не логичной, в таблицах стилей - куча избыточностей и неправильно объявленных наследований и всякое такое, и вот здесь по-хорошему нужно получить человеко-часы на то, чтобы спустя, скажем, несколько месяцев получить человеко-часы на работу, сесть, заново переосмыслить макет, переверстать шаблоны, переписать стили. Потому что концепция изменилась, а стили - только правились и дописывались. Редко когда бывает (хотя бывает,да), когда изначально внедрённый макет остаётся таким же, и при этом вполне гибким и спустя несколько месяцев разработки. Т.е. все нарасщиваемые страницы, и все затребованные элементы оформления - они там вполне добротно ложатся на уже спроектированный шаблон. Ах, Антон. Да не проблема же конечно же. Если есть макет, который можно проанализировать на предмет разметки главных контейнеров и элементов и написать красивую таблицу стилей. Я же пишу не о том, что вот у нас была дивная вёрстка, а потом Agile режим нас замордовал и случилась табличная вёрстка, нет. Просто стерильная и логичная вёрстка стала не стерильной и не логичной, в таблицах стилей - куча избыточностей и неправильно объявленных наследований и всякое такое, и вот здесь по-хорошему нужно получить человеко-часы на то, чтобы спустя, скажем, несколько месяцев получить человеко-часы на работу, сесть, заново переосмыслить макет, переверстать шаблоны, переписать стили.
Потому что концепция изменилась, а стили - только правились и дописывались.

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

]]> By: Zigzag http://blog.nundesign.com/design/2008/04/css-good/#comment-6161 Zigzag Thu, 01 May 2008 08:00:40 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6161 Татьяна, если честно, я не вижу логики. Ведь именно бестабличный макет легче всего видоизменять, чем табличный, в котором жестко задана та же модульная сетка. По поводу визивигов. Я когда-то тоже любил давать клиенту полную свободу. Теперь же я ее обрубаю по самое не балуй, только основные необходимые контролы оставляю в редакторе. Татьяна, если честно, я не вижу логики. Ведь именно бестабличный макет легче всего видоизменять, чем табличный, в котором жестко задана та же модульная сетка.

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

]]> By: Anton Naumov http://blog.nundesign.com/design/2008/04/css-good/#comment-6159 Anton Naumov Thu, 01 May 2008 06:03:23 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6159 н-да, про Liferay -- насчет Оперы я погорячился :) на самом деле у них другая тема была, в Опере работала нормально. тем не менее, продолжаю считать, что при должном уровне усердия и профессионализма -- дивная верстка не проблема. н-да, про Liferay — насчет Оперы я погорячился :) на самом деле у них другая тема была, в Опере работала нормально. тем не менее, продолжаю считать, что при должном уровне усердия и профессионализма — дивная верстка не проблема.

]]> By: Anton Naumov http://blog.nundesign.com/design/2008/04/css-good/#comment-6158 Anton Naumov Thu, 01 May 2008 06:00:18 +0000 http://blog.nundesign.com/design/2008/04/css-good/#comment-6158 насчет дивной верстки в портальных мордах: <a href="http://www.liferay.com" rel="nofollow">Liferay Portal</a>. ребята нарисовали портал с портлетами и очень красивую "дивную" тему. ничто никуда не разъезжатеся, ни в Опере, ни Лисе, ни в Осле, ни даже в Сафари. может быть все-таки дело в руках? или в лени? или и в том, и в другом? насчет эволюционного прототипирования: дык Agile, однако. так теперь часто, если не сказать почти всегда. только ПМы от Agile, не всгда профи. очень хочется красиво выглядеть и тогда разработку "мы вот тут чуть-чуть подправим, вот тут слегка подмажем, здесь пару бажков пофиксим, а вот тут добавим функционала и успеем в срок, а сроку у нас на все неделя" называют красиво Agile. а с другой стороны именно Agile требует профессионализма и ПМа, и аналитика, и всей команды. Waterfall АКА Cascade как-раз прощает промашки в начальных сроках, с аналитикой вообще проблем нет, и команда может подтянуться до нужного уровня в процессе Elaboration. а в Agile нужно садиться и "давать стране метал". и про компоненты -- не только в .Net. везде, причем как правило по итогу выгребать приходится гораздо больше проблем именно с табличной версткой компонента, когда нужно его красиво оформить или еще что-то с ним сделать. но зато, при разработке таблицой быстрее. альтернатива есть -- писать сайт руками, контролы делать на HTML + JS. а это значит +2 человека в команду. но это не оправданный оптимизм, в реальности +4 разработчика и +2 тестера. вариант реальный только если заказчик маньяк валидной верстки (что само по себе плохо, я предпочтиаю заказчика, который фанат успешного бизнеса, тогда проблем с переговорами и взглядом на концепцию меньше, а пользы больше -- платит регулярно, нацелен на результат и не лезет "учить жить"). так что врядли найдется контора, которая в качестве технологии разработки использует не компонентную модель, разве что вэб-студия. с другой стороны компоненты тоже на месте не стоят, я надеюсь что скоро и они будут рендерить нормальный HTML, тем более что это совсем не сложно. насчет дивной верстки в портальных мордах: Liferay Portal. ребята нарисовали портал с портлетами и очень красивую “дивную” тему. ничто никуда не разъезжатеся, ни в Опере, ни Лисе, ни в Осле, ни даже в Сафари. может быть все-таки дело в руках? или в лени? или и в том, и в другом?
насчет эволюционного прототипирования: дык Agile, однако. так теперь часто, если не сказать почти всегда. только ПМы от Agile, не всгда профи. очень хочется красиво выглядеть и тогда разработку “мы вот тут чуть-чуть подправим, вот тут слегка подмажем, здесь пару бажков пофиксим, а вот тут добавим функционала и успеем в срок, а сроку у нас на все неделя” называют красиво Agile. а с другой стороны именно Agile требует профессионализма и ПМа, и аналитика, и всей команды. Waterfall АКА Cascade как-раз прощает промашки в начальных сроках, с аналитикой вообще проблем нет, и команда может подтянуться до нужного уровня в процессе Elaboration. а в Agile нужно садиться и “давать стране метал”.
и про компоненты — не только в .Net. везде, причем как правило по итогу выгребать приходится гораздо больше проблем именно с табличной версткой компонента, когда нужно его красиво оформить или еще что-то с ним сделать. но зато, при разработке таблицой быстрее. альтернатива есть — писать сайт руками, контролы делать на HTML + JS. а это значит +2 человека в команду. но это не оправданный оптимизм, в реальности +4 разработчика и +2 тестера. вариант реальный только если заказчик маньяк валидной верстки (что само по себе плохо, я предпочтиаю заказчика, который фанат успешного бизнеса, тогда проблем с переговорами и взглядом на концепцию меньше, а пользы больше — платит регулярно, нацелен на результат и не лезет “учить жить”). так что врядли найдется контора, которая в качестве технологии разработки использует не компонентную модель, разве что вэб-студия. с другой стороны компоненты тоже на месте не стоят, я надеюсь что скоро и они будут рендерить нормальный HTML, тем более что это совсем не сложно.

]]>