LabVIEW Portal

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

Borjomy_1 писал(а):По ГОСТу языки мешать не допускается.Нам за такое по рукам линейкой дают. График не подписан, легенд шкал и плотов нет...в РППО на этот объект невозможно однозначно указать в тексте.

Кстати, еще одна фишка с именами шкал: они высвечиваются, когда курсор на ось наводим.

Kosist писал(а):А вот это и первый сигнал - если к интерфейсу нужно "привыкать", значит он - не user-friendly. Любая программа, даже для запуска ракеты на Луну, должна быть понятна с первого взгляда. Просто во многих случаях, юзер получает все as-is, и поэтому молчит, и не жалуется...

Не, никакого сигнала нет. К любому интерфейсу придётся какое-то время привыкать. Скажу больше: это может занять у кого-то 10 минут, а у кого-то целый день. Ну вот я пример привёл про фишки в различных ОС. Эти решения в плане GUI оч классные и удобные, но к ним нужно привыкнуть. Всё ок)

Пр это правая стенка,лев - левая. Баз - базовая, нб- не базовая. В данном случае находится в словаре обслуживающего персонала

Borjomy_1 писал(а):Пр это правая стенка,лев - левая. Баз - базовая, нб- не базовая. В данном случае находится в словаре обслуживающего персонала

Вот видите - так само можно сказать, что "1" - сигнал с первого канала, "2" - со второго. А схема подключения приведена в документации для установки (для тестеров, например, мануал находится прямо при тестере, т.е. оператор может его открыть и прочитать сразу прямо на месте). Все относительно...

Kosist писал(а):

Borjomy_1 писал(а):Пр это правая стенка,лев - левая. Баз - базовая, нб- не базовая. В данном случае находится в словаре обслуживающего персонала

Вот видите - так само можно сказать, что "1" - сигнал с первого канала, "2" - со второго. А схема подключения приведена в документации для установки (для тестеров, например, мануал находится прямо при тестере, т.е. оператор может его открыть и прочитать сразу прямо на месте). Все относительно...

Наименования стенок вполне читаемы и явно их обозначают. А вот нерусские обозначения это явный прокол. Как и отсутствие названия графика

Наименования стенок - это специальные металлургические термины. И обозначены они так, а не иначе, по согласованию с технологическим персоналом. На разных комбинатах приняты разные обозначения. Поэтому названия стенок вынесены в настройки.
Базовая стенка - та, на которую опирается сляб при изгибе. Небазовая- противоположная. Мало того, если смотреть на слиток в направлении выхода слитка, то левые и правые стенки будут одни. А если со стороны диспетчерской, то наоборот. Обозначать привычными словами необходимо, чтобы персонал и у кристаллизатора и в диспетчерской не путался и не тратил время на то, чтобы перевернуть картинку.
А когда половина надписей на английском, а другая на русском, то это как минимум неудобно. В защиту своего интерфейса скажу, что у меня коды стенок "wall" вижу только я, как наладчик системы и только при запуске в эксплуатацию. Технологический персонал эту вкладку не видит.
Что касается нелюбви к стандартным индикаторам, то тут есть нюанс. Во первых поведение стандартных индикаторов, контролов и элементов интерфейса прогнозируемо для тех, кто пользуется этой программой и другими. Его нет необходимости описывать подробно. В скадах вы вообще не можете оперировать нестандартными объектами. Во вторых персоналу эти рюшечки не нужны. Эти рюшечки нужны для самовыражения программиста. Часто бывает так, что за ними скрывается убогость функционала.

И какой функционал в понимании считается убожеством?

Это просто. Например нужен контрол Numeric. Правда, он нам не нравится, тогда мы пытаемся сделать свой. Но на полную проработку функционала времени не хватает, да и думаю, большая часть Numeric защищена патентами. Поэтому создается свой красивый, но пустой. А еще хуже, когда разработчик начинает считать себя богом и делает интерфейс (например) Numeric по-своему, нестандартно относительно наиболее часто употребляемых подобных компонентов. Например ему вздумалось копирование и вставку из буфера обмена назначить на другие клавиши. И не смейтесь - я такое видел, причем в очень серьезной программе, которую продают за немаленькие деньги.

Вот это и составляет моё впечатление о GUI. Поэтому у Borjomy_1 я отметил следующее: полупустые вкладки, цветовая гамма не очень, на некоторых вкладках элементы неряшлево расположены, кастом никакой, масштабируемости нет etc. Вишенкой на торте будет Tab в Tab-е и еще в одном Tab-е. И там, где-то глубоко сидит еще один Tab, да же?

Эта программа писалась с 2009 года. Тогда-же были заложены основные принципы. И знаете, меня рюшечки вот в последнюю очередь интересовали. Основная работа производится со вкладками на рисунках 1 и 2. Их видит персонал 99% времени (мало того, в некоторых случаях у оператора вообще нет ни мыши ни клавиатуры, работает только одно окно). И ему как-то по барабану, что не очень ровно что-то расположено или цвет серый. Это вам как разработчику хочется, чтобы было красиво. А человек пялится в этот экран по 8 часов непрерывно! Все промышленные скады, к которым относится и моя система, сделаны в СЕРОЙ палитре.
Что касается табов, то они имеют одно неоспоримое преимущество: по сравнению с нестандартными интерфейсами проще производить техническую поддержку и описывать в документации. Звонит человек и спрашивает чего делать? Ты ему и говоришь: идете на вкладку такую-то, далее такую-то и делаете то-то в том-то и том-то окошке. Объяснять что подразумевается под конкретным изображением компонента не требуется. А вот как у вас объяснять вслепую, я не знаю.

Проблема с обозначениями отпадает если работать по ТЗ, а в комплекте с разработанным изделием идет РЭ и ТУ.
К вопросу о "навороченности" интерфейса, то как правило он нужен только программисту, чтобы попонтоваться перед другими программистами (потому как производство плюшек просто не поймет, да и не нужно им это), либо впаривания заказчику, чтобы на приемке у него "разбежались глаза" и он не заметил явных недочетов, либо он непоняв что-то постесняется в этом признаться (бывает и такое. не срабатывает только на военной приемке). Даже идея xgrapher'а, на мой взгляд шикарная, внедряется с большими сложностями...

ps. Я все больше склоняюсь к совмещению контексного меню (свое для каждого элемента) на фоне в общем простого интерфейса.

Проблема с обозначениями отпадает если работать по ТЗ, а в комплекте с разработанным изделием идет РЭ и ТУ.

Кстати, собственноручное написание РППО, позволяет отточить интерфейс. Когда начинаешь описывать программу словами, бывает, становится ясно, что надо переделывать, ибо это криво или черезчур сложно описывается.

Borjomy_1 делать копирование - это не GUI, это оплошность разработчика. Непосредственно к GUI никакого отношения не имеет.
Рюшечки и функциональность не мешают друг другу. Просто кому-то в лом делать, кто-то просто не умеет, кто-то без фантазии в голове, либо не принято(корпоративная этика разработчиков типа).
Пример: пишем софт для одной компании. Делаем всё стандартными элементами и отдаём. Юзеру нравится, всё ничтяк. Настало время апгрейда софта в этой же компании и тут мы выкатываем кастомный GUI, весь глянцевый,блестящий и с новой концепцией построения. Конечно же у юзера задымится известное место и он попросит сделать так, как было раньше, ведь привыкли уже. И плевать он хотел на красоту.
Поэтому следует 10 раз подумать, какую концепцию GUI заложить в проект изначально. Как можно всё скомпоновать, что можно объединить в одном окне, но с визуальным разделением. То есть приходим к варианту с рюшечками. Либо пилим по старинке.
Мне кажется, этот конкурс нацелен именно на получение новых идей к построению GUI. И не играет роли в какой области что используется и какие требования выкатывал заказчик и сколько часов он сидит за компом. То есть мы(разработчики) обмениваемся опытом

Коллеги, просьба быть уважительнее к чужим разработкам и друг другу, у нас даже есть правило соответствующее, вы же не хотите нарушать правила форума? Обсуждать разработки коллег можно в корректной форме, без "сорных словечек")
Немного почистил тему.

делать копирование - это не GUI, это оплошность разработчика. Непосредственно к GUI никакого отношения не имеет.

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

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

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

17

Для себя я пришел к следующему виду интерфейса:

1) есть стандартная часть интерфейса, которую я практически не меняю уже несколько лет и заказчик ее менять не может. Начиналось все с варианта, показанного на конкурсе лет пять назад: http://www.labviewportal.org/ru/galerej ... y&catid=24

2) и есть закладка, где интерфейс согласовывается уже с каждым заказчиком отдельно, обычно там располагается 3D модель или рисунок испытательного стенда

Можно это назвать интерфейсом для испытательных стендов.

Лёша, узнаю знакомые кнопки)))
Кстати вопрос - у тебя узла станка анимированы? Т.е. движутся при работе программы? Или просто статичны?