Komentarze do: Adobe Thermo, a szybkie prototypowanie http://blog.flextech.pl/2008/06/19/adobe-thermo-a-szybkie-prototypowanie/ wszystko o RIA Flex Flash AIR LiveCycle Media Server Catalyst Paweł Cichoń Wed, 21 Dec 2011 18:06:53 +0100 http://wordpress.org/?v=abc hourly 1 Autor: Paweł Cichoń http://blog.flextech.pl/2008/06/19/adobe-thermo-a-szybkie-prototypowanie/comment-page-1/#comment-437 Paweł Cichoń Wed, 25 Jun 2008 08:19:34 +0000 http://blog.flextech.pl/2008/06/19/adobe-thermo-a-szybkie-prototypowanie/#comment-437 W sumie wydaje mi się, że w Thermo kwestia prototypowania będzie na dosyć wysokim poziomie abstrakcji i raczej nie będzie zahaczała o stanowość, a raczej po prostu o prototypy poszczególnych widoków. Odejście od listwy czasowej też chyba nie nastąpi, wynika to z prostego faktu - otóż projektowanie transformacji w oparciu o listwe czasu (nawet jeżeli będzie ona abstrakcyjna) bedzie o wiele bardziej intuicyjne dla projektantów/analityków - a z tego co widać do takach osób celuje Thermo, niż przykładowo do programistów. Adobe Thermo w moim odczuciu, nie będzie narzedziem do prototypowania niskiego poziomu, ale z pewnością pierwszym krokiem w tym kierunku. W sumie wydaje mi się, że w Thermo kwestia prototypowania będzie na dosyć wysokim poziomie abstrakcji i raczej nie będzie zahaczała o stanowość, a raczej po prostu o prototypy poszczególnych widoków. Odejście od listwy czasowej też chyba nie nastąpi, wynika to z prostego faktu – otóż projektowanie transformacji w oparciu o listwe czasu (nawet jeżeli będzie ona abstrakcyjna) bedzie o wiele bardziej intuicyjne dla projektantów/analityków – a z tego co widać do takach osób celuje Thermo, niż przykładowo do programistów. Adobe Thermo w moim odczuciu, nie będzie narzedziem do prototypowania niskiego poziomu, ale z pewnością pierwszym krokiem w tym kierunku.

]]> Autor: Michał Małaj http://blog.flextech.pl/2008/06/19/adobe-thermo-a-szybkie-prototypowanie/comment-page-1/#comment-409 Michał Małaj Mon, 23 Jun 2008 12:04:54 +0000 http://blog.flextech.pl/2008/06/19/adobe-thermo-a-szybkie-prototypowanie/#comment-409 Obserwując narzędzia do prototypownia aplikacji np: Serena Prototype Composer czy narzędzia do tworzenia interaktywnych aplikacji typu Microsoft Expression Blend zaczynam zastanawiać się na jakiej bazie chcą oprzeć "wizualizację" prototypu. Po pierwsze: odejście od listwy czasu znanej z Flash IDE czy MS Vizact 2000 Po drugie: rozdzielenie projektowanie designu od projektowania interakcji (MS Visual Studio jest klasycznym przykładem jakie są skutki łaczenia w jednym projektowania designu które jest generowane automatyczne a interakcję podporządkuje się kodowi wygenerowanego designu) Po trzecie: odejscie od interakcji opartej na zdarzeniach na rzecz interakcji opartej na stanach Twórca koncetruje się tym jakim "stanie" jest dany model aplikacji. Połączenie wzorca MVC z obsługą stanów modułów w Flex Framework pozwala na tworzenie aplikacji czasu rzeczywistego dla internetu. Pozostaje tylko pytanie jak wyobrażacie sobie tworzenie aplikacji w Thermo. Ja wyobrażam sobie że to jest wygenerowanie szkieletu kodu aplikacji coś jak w przypadku Cairngorna i wtedy można by zacząć pracę w graficznym środowisku IDE Thermo. Projektant definiuje model, potem okresla stany, Thermo pozwoli na bazie zdefiniowanych stanów generuje widoki i potem pozostaje już na łączenie interakcji pomiędzy widokami za pomocą myszki np: przycisk w pewnym widoku na jednym stanie prowadzi do widoku do innego widoku w tym samym stanie danych modelu - nawet jak go nie ma jeszcze to Thermo go wygeneruje Wybieramy stan np: rejestrację, tworząc widok logowania przesuwając myszkę nad przyciskiem logowanie z menu podręcznego wybieramy nowy widok i nazywamy go wypełnianie określamy jego wywołanie np: onclick. W ten sposób nie trzeba pisać kodu do śledzenia zależnościami pomiędzy widokami bo tym zajmie się wygenerowany kod kontrolera. Obserwując narzędzia do prototypownia aplikacji np: Serena Prototype Composer czy narzędzia do tworzenia interaktywnych aplikacji typu Microsoft Expression Blend zaczynam zastanawiać się na jakiej bazie chcą oprzeć “wizualizację” prototypu.

Po pierwsze: odejście od listwy czasu znanej z Flash IDE czy MS Vizact 2000
Po drugie: rozdzielenie projektowanie designu od projektowania interakcji (MS Visual Studio jest klasycznym przykładem jakie są skutki łaczenia w jednym projektowania designu które jest generowane automatyczne a interakcję podporządkuje się kodowi wygenerowanego designu)

Po trzecie: odejscie od interakcji opartej na zdarzeniach na rzecz interakcji opartej na stanach Twórca koncetruje się tym jakim “stanie” jest dany model aplikacji. Połączenie wzorca MVC z obsługą stanów modułów w Flex Framework pozwala na tworzenie aplikacji czasu rzeczywistego dla internetu.

Pozostaje tylko pytanie jak wyobrażacie sobie tworzenie aplikacji w Thermo. Ja wyobrażam sobie że to jest wygenerowanie szkieletu kodu aplikacji coś jak w przypadku Cairngorna i wtedy można by zacząć pracę w graficznym środowisku IDE Thermo.
Projektant definiuje model, potem okresla stany, Thermo pozwoli na bazie zdefiniowanych stanów generuje widoki i potem pozostaje już na łączenie interakcji pomiędzy widokami za pomocą myszki np: przycisk w pewnym widoku na jednym stanie prowadzi do widoku do innego widoku w tym samym stanie danych modelu – nawet jak go nie ma jeszcze to Thermo go wygeneruje

Wybieramy stan np: rejestrację, tworząc widok logowania przesuwając myszkę nad przyciskiem logowanie z menu podręcznego wybieramy nowy widok i nazywamy go wypełnianie określamy jego wywołanie np: onclick. W ten sposób nie trzeba pisać kodu do śledzenia zależnościami pomiędzy widokami bo tym zajmie się wygenerowany kod kontrolera.

]]>