Использование Expression Blend Sketchflow - Актуальность для внедрения программирования Silverlight?
Недавно я программировал веб-приложения, используя Silverlight & Ria Services. Мне стало известно о возможности включить использование Expression Blend Sketchflow в мой цикл разработки как способ создания быстрых прототипов для демонстрации клиентам при использовании гибкой методологии. Мне было трудно использовать sketchflow, поскольку кажется, что идея, лежащая в его основе, просто не соответствует идее программирования приложения silverlight. По сути, я пытаюсь сказать, что для того, чтобы я смог создать быстрый прототип для клиента в SketchFlow, мне нужно немного программировать, чтобы показать реальную функциональность потенциального приложения, но это не так. весь смысл набросков, чтобы пропустить фазу программирования и "дизайн" приложения, чтобы дать клиенту..... Мне трудно сказать то, что я хочу сказать, но я чувствую, что пропустил что-то с использованием функции SketchFlow....
Сценарий. Управляемому данными приложению требуется несколько наборов данных для отображения реляционных данных. Если я запрограммирую это сразу, то это нормально, но не долго. Однако, если я использую SketchFlow, я не могу показать тот же объем функций (без каких-либо битов кодирования) - поймать мой дрифт!!?
Мнения и комментарии / советы приветствуются.....
2 ответа
Мы используем SketchFlow и получили отличный отклик руководства. На ум приходят две вещи: SketchFlow, очевидно, лучше документа Word, поскольку клиенты могут видеть приложение в действии. С другой стороны, вы подчеркиваете, что для этого требуется некоторое программирование, и это правда. Причина, по которой это лучше, чем создание прототипа в Silverlight (и это может звучать странно), заключается в том, что прототип получается волнистым и комичным. Это не похоже на реальное приложение. Слишком часто в моем опыте менеджмент видел работающий прототип и почему-то пришел к мнению, что "код уже выполнен на 50%, я видел его!" Как разработчик, вы можете знать, что код прототипа является мусором и его следует выбросить, но руководство не знает об этом. Я могу вспомнить ряд производственных приложений, над которыми я работал, которые все еще работают с прототипом кода, потому что руководство увидело его и решило ускорить реализацию проекта, SketchFlow помогает облегчить это, предоставляя вам выразительную мощь работающего приложения.
Вы не можете думать о прототипе в Sketchflow как о "приложении". Думайте об этом как о серии раскадровок, которые связаны простой навигацией. Если вы обнаруживаете, что программируете программный код в sketchflow, вы, вероятно, слишком стараетесь, чтобы он работал как приложение.
Вы должны думать о эскизе как о представлении простого конечного автомата, где каждый экран является состоянием. Я думаю, что соблазн программистов - погрузиться в "как" вместо того, чтобы сказать "что". Каждый экран представляет, что должно быть сделано и как он должен выглядеть, но он не должен описывать дизайн / архитектуру того, как это достигается. Если вам нужно заменить набор элементов управления на экране и заменить их на другие, не программируйте его, создайте новый экран!
Например, я хотел создать прототип эскиза, в котором система меню была бы похожа на главное меню в программном обеспечении Zune (меню в меню). Я потратил день на то, чтобы крутить колеса, пытаясь запрограммировать экран компонентов с состояниями и анимацией, которые бы открывали или скрывали подменю. На следующий день мне пришло в голову создать отдельный экран компонентов для каждого элемента в главном меню, и теперь у меня есть 3 экрана компонентов, которые не содержат программирования, кроме простой навигации.
Что касается реляционных данных, я думаю, что в макете следует ожидать разумного количества "размахивания руками". Требование макета потока эскизов, чтобы иметь строгие наборы данных, которые отображают "реальные" данные, похоже на то, что вы разговариваете со своей аудиторией, как будто у них недостаточно воображения, чтобы понять цель. Но это мои 2 цента...