Комментарии на: Разработка интерфейсов в неприспособленных для этого условиях http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/ Fri, 09 Sep 2011 10:49:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 От: Denis http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1791 Denis Tue, 27 Oct 2009 09:05:46 +0000 http://blog.nundesign.com/?p=282#comment-1791 Согласен, если программер не может...значит должен смоч! Согласен, если программер не может…значит должен смоч!

]]> От: podarok http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1790 podarok Fri, 19 Sep 2008 14:34:27 +0000 http://blog.nundesign.com/?p=282#comment-1790 гм гм

]]> От: nundesign http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1789 nundesign Fri, 19 Sep 2008 14:09:39 +0000 http://blog.nundesign.com/?p=282#comment-1789 Це дуже цiкава думка, я обов'язково напишу канадським керівникам про ваші ради. Дякую. Це дуже цiкава думка, я обов’язково напишу канадським керівникам про ваші ради. Дякую.

]]> От: podarok http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1788 podarok Fri, 19 Sep 2008 14:05:55 +0000 http://blog.nundesign.com/?p=282#comment-1788 ті, хто пишуть і затверджують ТЗ - ті і повинні закладати ці моменти ті, хто пишуть і затверджують ТЗ – ті і повинні закладати ці моменти

]]> От: nundesign http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1787 nundesign Fri, 19 Sep 2008 11:47:27 +0000 http://blog.nundesign.com/?p=282#comment-1787 Podarok: який ще вiддiд планування? Немає у нас нiякого вiддiда планування. Тiльки программiсти та дизайнери. Podarok: який ще вiддiд планування? Немає у нас нiякого вiддiда планування. Тiльки программiсти та дизайнери.

]]> От: podarok http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1786 podarok Fri, 19 Sep 2008 11:32:38 +0000 http://blog.nundesign.com/?p=282#comment-1786 погоджуся з Anton Naumov Відділ планування повинен передбачати можливі шляхи розвитку проекту методами універсальності. А з хардкода ржу. Технології є, які це обходять без проблем. погоджуся з Anton Naumov
Відділ планування повинен передбачати можливі шляхи розвитку проекту методами універсальності.

А з хардкода ржу. Технології є, які це обходять без проблем.

]]> От: nundesign http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1785 nundesign Fri, 27 Jun 2008 08:26:52 +0000 http://blog.nundesign.com/?p=282#comment-1785 Не-не, локализация интерфейса проходит без переписывания "с нуля". Это я вчера невнятно изъяснялась, видимо. Вообще я действительно довольно часто слышу "это нельзя реализовать" (на данном этапе) или "чтобы разобраться, как такое сделать, нужно N времени", но не могу озвучить или объяснить, почему. Может, проблема в технологии, может, в том, что программеры наши опыта набираются на текущих проектах, а не на предыдущих местах работы. С этими глобальными переменными вообще какая-то муть, я вроде и понимаю, что мне недоговаривают или вешают лапшу, но поспорить-то не могу? К примеру в <strong>одном</strong> интерфейсном окне на одной подпанельке выведены одни тексты (скажем, дерево элементов), на второй подпанельке - другие тексты (скажем, информационные пояснялки). Я вижу, что там используется РАЗНЫЙ шрифт. Он почти одинаковый. Но не один, точно. А мне программер расказывает, что и туда, и туда свойства шрифта задаются из одной глобальной переменной, поэтому он не может быть разный. Я ему в фотошопе показываю (вырезаю буковки и ставлю их рядом), что буквы не совпадают. А он мне опять про особености задания свойств для всего... Да, а локализацию, хоть она почти и доделана, пусть и не оптимально, действительно изначально не планировали, потому что не было известно, пойдёт ли вообще эта программа в серьёзную разработку или нет. А про перепроектирование с нуля - это не в контексте локализации, а в контексте того, что на сегодняшний день глобальная задача-то отличается уже от той, что озвучивалась поставщиком идеи и постановщиком задачи полтора-два месяца назад. От трёх простых действий к многофункциональному приложению с кучей настроек, отчётов, свойств и шедулеров. По традиционному сценарию "всё чудесно, а давайте добавим ещё такую-то фичу". Не-не, локализация интерфейса проходит без переписывания “с нуля”. Это я вчера невнятно изъяснялась, видимо.
Вообще я действительно довольно часто слышу “это нельзя реализовать” (на данном этапе) или “чтобы разобраться, как такое сделать, нужно N времени”, но не могу озвучить или объяснить, почему. Может, проблема в технологии, может, в том, что программеры наши опыта набираются на текущих проектах, а не на предыдущих местах работы.

С этими глобальными переменными вообще какая-то муть, я вроде и понимаю, что мне недоговаривают или вешают лапшу, но поспорить-то не могу? К примеру в одном интерфейсном окне на одной подпанельке выведены одни тексты (скажем, дерево элементов), на второй подпанельке – другие тексты (скажем, информационные пояснялки). Я вижу, что там используется РАЗНЫЙ шрифт. Он почти одинаковый. Но не один, точно. А мне программер расказывает, что и туда, и туда свойства шрифта задаются из одной глобальной переменной, поэтому он не может быть разный. Я ему в фотошопе показываю (вырезаю буковки и ставлю их рядом), что буквы не совпадают. А он мне опять про особености задания свойств для всего…

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

А про перепроектирование с нуля – это не в контексте локализации, а в контексте того, что на сегодняшний день глобальная задача-то отличается уже от той, что озвучивалась поставщиком идеи и постановщиком задачи полтора-два месяца назад. От трёх простых действий к многофункциональному приложению с кучей настроек, отчётов, свойств и шедулеров. По традиционному сценарию “всё чудесно, а давайте добавим ещё такую-то фичу”.

]]> От: Anton Naumov http://blog.nundesign.com/%d0%b4%d0%b8%d0%b7%d0%b0%d0%b9%d0%bd/2008/06/designing-interfac/#comment-1784 Anton Naumov Fri, 27 Jun 2008 03:57:26 +0000 http://blog.nundesign.com/?p=282#comment-1784 зато я программист. и проблема на самом деле только одна -- <strike>в ДНК</strike> в подходах. и вот почему: 1) ваша проблема локализации аж ни разу не уникальна, я скажу больше -- это классическая проблема десктопных приложений. самые проблемные языки немецкий, испанский, иврит и фарси. то, что приложение будет нужно локализовывать не было выявлено на этапе разработки архитектуры проетка? минус человеку, занимавшему анализом идеи. кстати, если твои коллеги не знают, Канада официально двуязычная страна, уже поэтому можно <strong>изначально</strong> планировать локализацию, а где французский, там и испанский -- Штаты-то рядом, а если языков уже три, так проще универсальное решение в планы заложить. 2) что-то где-то у кого-то захардкоджено? пусть пойдет и помоет руки с мылом. а когда вернется, пусть почитает про XML, INI и прочие форматы хранения настроек. и никогда, никогда больше так не делает. 3) у вас классический Agile или эволюционное прототипирование. и если люди, которые разрабатывают архитектуру решения, не научились делать ее гибкой.... наверное нужно поставить делать архитектуру других людей 4) если бы я был поставщиком задания и мне бы рассказали, что для того чтобы локализовать интерфейс мне нужно потратить время (а следовательно и деньги) на <strong>перепроектировать и переписать все с нуля</strong>, я бы не то что удивился. я бы решил, что моя команда либо абсолютно не компетентна (что врядли), либо просто пытается меня "обуть". зато я программист. и проблема на самом деле только одна — в ДНК в подходах. и вот почему:
1) ваша проблема локализации аж ни разу не уникальна, я скажу больше — это классическая проблема десктопных приложений. самые проблемные языки немецкий, испанский, иврит и фарси. то, что приложение будет нужно локализовывать не было выявлено на этапе разработки архитектуры проетка? минус человеку, занимавшему анализом идеи. кстати, если твои коллеги не знают, Канада официально двуязычная страна, уже поэтому можно изначально планировать локализацию, а где французский, там и испанский — Штаты-то рядом, а если языков уже три, так проще универсальное решение в планы заложить.
2) что-то где-то у кого-то захардкоджено? пусть пойдет и помоет руки с мылом. а когда вернется, пусть почитает про XML, INI и прочие форматы хранения настроек. и никогда, никогда больше так не делает.
3) у вас классический Agile или эволюционное прототипирование. и если люди, которые разрабатывают архитектуру решения, не научились делать ее гибкой…. наверное нужно поставить делать архитектуру других людей
4) если бы я был поставщиком задания и мне бы рассказали, что для того чтобы локализовать интерфейс мне нужно потратить время (а следовательно и деньги) на перепроектировать и переписать все с нуля, я бы не то что удивился. я бы решил, что моя команда либо абсолютно не компетентна (что врядли), либо просто пытается меня “обуть”.

]]>