СПО и проектирование интерфейса пользователя (Дмитрий Литвинов, OSEDUCONF-2024) — различия между версиями

;{{SpeakerInfo}}: {{Speaker|Дмитрий Литвинов}}
<blockquote>
В данной статье рассматривается проблема острой нехватки программных продуктов с открытым 
исходным кодом для работы в сфере дизайна и, в частности, проектирования интерфейсов.
</blockquote>

{{VideoSection}}
{{vimeoembed|990136042|800|450}}
{{youtubelink|}}

{{SlidesSection}}
[[File:СПО и проектирование интерфейса пользователя (Дмитрий Литвинов, OSEDUCONF-2024).pdf|left|page=-|300px]]

{{----}}

== Thesis ==
* UI/UX, дизайн интерфейса.

Рассмотрим модель разработки программного обеспечения, далее просто ПО, под названием «Водопад»<ref name="litv-1"><i>Alva, Thomas</i>, Ещё раз про семь основных методологий разработки, 2015, [https://habr.com/ru/companies/edison/articles/269789/]</ref>:

[[File:osseduconf-2024-litvinov-litvinov-litv.png|center|640px|thumb|Цикл разработки программного обеспечения]]


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

Итак, мы видим пять этапов разработки ПО, по крайней мере два из которых не имеют очевидной зависимости 
от использования свободного программного обеспечения (СПО). Это этап номер один «Проектирование» и этап 
номер пять «Поддержка». В целом к ним можно добавить и четвёртый этап, но технологий тестирования много, 
и некоторые могут включать в себя тестирование с применением различного ПО. 

Намного сильнее зависят от типа лицензии ПО оставшиеся два этапа: это «Дизайн» и «Кодирование». 

И если у программистов при переходе на СПО и Linux имеется обширный инструментарий, то дизайнеры сталкиваются 
с почти полным отсутствием альтернатив ПО в данной сфере деятельности. Таким образом, пока также отсутствует 
возможность внедрения СПО для проектирования и дизайна в образовательный процесс в школах, колледжах и вузах.

Ниже приведена таблица программных продуктов, которые могут быть применены для проектирования интерфейсов 
пользователя на разных стадиях развития продукта — от проектирования интерфейса до презентации готового 
продукта заказчику. Данные программы имеют, в той или иной степени, большие сообщества пользователей, 
а значит, достаточный объём учебного материала. 

[[File:osseduconf-2024-litvinov-litvinov-litv1.png|center|640px|thumb|Сравнительный анализ СПО для дизайна и проектирования интерфейсов]]

Если убрать из рассмотрения несвободное и ПО под санкциями, а также ПО, которое не создано изначально 
для дизайна интерфейсов, из рассмотренных продуктов с полным циклом проектирования интерфейса останется 
только <tt>Penpot</tt>. Это проект с небольшим сообществом пользователей и таким же малым количеством 
учебного материала, который всё ещё находится в разработке. Но так как он является аналогом, в хорошем 
смысле этого слова, его проприетарным конкурентам в лице <tt>Figma</tt>, <tt>Sketch</tt> и <tt>Lunacy</tt>, то 
переход на него может пройти достаточно гладко. Автору статьи потребовалось не более пятнадцати минут, 
чтобы освоиться с функционалом данного приложения.

Но есть и ряд проблем. Во первых, это веб-приложение, которое, как и его веб-конкуренты, имеет существенные минусы: 
#  привязка к наличию и качеству интернет-соединения;
#  техническое ограничение одной вкладки браузера, в среднем, в 2 гигабайта оперативной памяти<ref name="litv-2"><i>Figma Learn</i>, Reduce memory usage in files, 2024, [https://help.figma.com/hc/en-us/articles/360040528173-Reduce-memory-usage-in-files]</ref>;
#  собственно сам браузер, требующий и потребляющий немалое количество ресурсов «железа» в отличие от нативных решений.

В теории, эти минусы обходятся установкой <tt>Penpot</tt> в собственный контейнер<ref name="litv-3"><i>PenPot</i>, Self-host Penpot, 2024, [https://penpot.app/self-host]</ref>. 

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

Второе ограничение — разделение проекта на мелкие подпроекты и библиотеки. А третье — это необходимость обновления парка рабочих машин.

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

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

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


{{----}}
[[File:{{#setmainimage:СПО и проектирование интерфейса пользователя (Дмитрий Литвинов, OSEDUCONF-2024)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->

<references/>

[[Категория:OSEDUCONF-2024]]
[[Категория:Draft]]
[[Категория:СПО в образовании]]