Usabilidoido: Menu Principal

Rich Internet Applications: prós e contras

Há alguns dias começou uma das melhores discussões do ano na lista Aifia-pt como o assunto RIA, esse novo conceito de aplicação Web que a Macromedia está consolidando. Quem quiser acompanhar direto no histórico da lista, fiquem à vontade, são no total 36 mensagens muito pertinentes. Selecionei alguns trechos que julguei interessantes para quem tem pressa:

Thais Mattoso abriu o tópico:

A I-group (http://www.i-group.com.br), recentemente se tornou uma agência de marketing digital da Macromedia aqui em São Paulo.

(...)

Eu já tive a oportunidade de trabalhar com essa tecnologia, fazendo um anteprojeto visando a reestruturação de um "carrinho de compras" de um site de e-commerce e achei muito legal. O grande lance agora, é nos especializarmos e divulgarmos isso entre nossos clientes deixando claro de que o flash deixou de ser algo estético para se tornar muito funcional. No site Macrocenter vcs irão encontrar detalhes sobre essa
tecnologia, alguns cases interessantes e cursos de formação na área.

Irapuan Martinez criticou:

Dizem que o Flash é rico. Seria o conteúdo em HTML pobre?

Flash tem essa característica: Você está restrito ao que o desenvolvedor criou. Se os links abrem na janela corrente ou em novas janelas, não está na mão controlar isso, quem controla é o web designer. Deep links? Selecionar textos? Bookmarkear uma página? Zoom font? Chavear estilos? Boormarklets? Barras de rolagens movidas ao scrollwheel do mouse? Conteúdo acessível a qualquer resolução de vídeo? Style media types? Separação de informação da formatação? Acessiiblidade? Indexabilidade?

Nada disso é suportado - salvo se o desenvolvedor do Flash gastou horas de produção desenvolvendo estas interações. No HTML, essas coisas podem ser consideradas inerentes ao formato.

Oh, claro, o HTML não tem texto voando, intermináveis transições e nem som. Dado o tempo que isso nos despediça, abençoado HTML.

Diante de tantas restrições que o Flash imputa ao usuário, ele merece ser chamado de "rico"?

Restrict Internet Applications, isso sim.

Eu apoiei

Flash é útil, mas não da forma como está sendo divulgada pelo
Macrocenter. Estão vendendo RIA como se fosse o santo graal da Web, que pudesse como num passe de mágicas enriquecer a experiência do usuário. Nenhuma tecnologia pode fazer isso, quem faz isso é quem proporciona a experiência, ou seja, a equipe de design do produto.

(...)

Se vocês entrarem num dos cases recomendados pelo Macrocenter, a loja virtual www.penatrilha.com.br, notarão algumas falhas que, provavelmente, passaram desapercebidas aos desenvolvedores, que foram até bem cuidadosos.

Será que valeu à pena perder a capacidade de um produto ser encontrado à partir de um buscador como o Google? Ou tratar mal usuários que possuem computadores desprovidos de placas aceleradoras 3D? Ou, bem, acho que vocês entenderam que esse não é o tipo de case que gosto de mostrar.

Amazon é uma excelente loja virtual sem Flash, ou melhor, agora estão usando Flash para exibir vídeos com merchandising subliminar, uma tacada de mestre, na minha opinião.

O segredo do Flash é usá-lo apenas para aquilo que só ele pode fazer. Site institucional em Flash não recomendo nem mesmo para o site do Macrocenter (o site da Macromedia, por exemplo, não é 100% Flash).

Maycom Souza defendeu:

De fato, é inegável que existe uma certa curva de aprendizado para se conseguir trabalhar em Flash programável e tudo mais. Penamos muito ara aprender e só agora estamos começando a dominar o processo de produção.

Por outro lado, a diferença de resultados entre um site normal e um site em RIA foi algo que eu só acreditei depois de ler e reler os relatórios dos clientes diversas vezes. Estamos falando de aumentos de 200, 300% nas vendas; de diminuição imensa no abandono de carrinhos de compra e de um usuário muito mais "preso" à navegação.

Daniel A. Gartner apoiou Maycom

É isso aí Maycon. Foco no resultado, e não na aplicação.

A empresa X pode até ter usado somente uma minoria do que o RIA pode proporcionar, mas se este pouco já fez diferença no negócio do cliente, então valeu a pena.

E mais, daqui pra frente a banda larga é caminho que as empresas estão trilhando. Ficar pensando como desenvolvedor de 56k, é no mínimo ficar míope para os avanços que a internet está proporcionando.

Caio Cesar corrigiu

Não; meus caros. o foco não é no resultado e nem na aplicação. o foco é no usuário. lembra dele? é ele quem usa a aplicação para executar um processo, visando um certo objetivo. o foco, portanto, deve ser ele. ponto final.

Não é uma caça às bruxas, há espaço a todos os formatos e todas as soluções, desde que, claro, bem aplicadas.

Irapuan Martinez retrucou:

Mas reduzir a burocracia da compra não é virtude do Flash, mas da usabilidade. Se pegar uma loja virtual "em HTML" e reduzir as etapas (promovendo a usabilidade), irá reduzir o abandono do carrinho também.

A Amazon patenteou um recurso de "compra em apenas um clique". Quer mais usabilidade que isto?

Falando nela, posso ir na Amazon e pegar uma URL precisa de um determinado produto e publicar em algum lugar, citar numa lista de discussão, repassar por mensagem instantânea. Flash, não tem como.

Salvo, claro, se o desenvolvedor se matou em alguns dias a mais de produção, tentanto imitar no Flash o que o HTML já tem embutido.

Tentar fazer o Flash usável e acessível é tentá-lo aproximar da experiência do HTML. Daí pergunto: Pra quê Flash então?

Ricardo Almeida defendeu o Flash

Nós já testamos o conceito enquanto empresa de planejamento Web, já colhemos os resultados e já fizemos as mais diversas análises - e se tem uma coisa que ninguém pode contestar é um relatório de retorno financeiro. Que, aliás, foi surpreendentemente alto. Somando isso a índices de satisfação de usuário altíssimos e a feedbacks sempre positivos, o que mais se pode esperar/desejar?

Irapuan Martinez manteve sua posição:

Flash, assim como banners, agrada olhos novatos. Com o tempo, começa a gerar resistência. Ninguém mais tem paciência para "Eye4U", por mais deslumbrados que ficamos quando acessamos a primeira vez.

Gabocorp relançou seu site dia desses. O pioneiro no Flash vez um trabalho que considerei lastimável. Flash cria resistência.

RIA quer provar que o Flash pode ser usado em e-comm e multimídia. Mas eles ainda não resolveram os diversos problemas que o player ainda tem hoje em dia. Então, aonde está a novidade?

Eu apoiei:

Exatamente. Se começarmos a exaltar tecnologias que trazem retorno a curto prazo sem segurança do retorno a médio e longo prazo, podemos cair numa nova bolha. Números como aumento de 300% nas vendas, assim, de uma hora pra outra, costumam sinalizar uma queda vindoura.

Precisamos de análises a médio e longo prazo. O case do Broadmoor Hotel já é bem antigo e pelo que li parece que deu certo. Considero uma RIA muito bem feita.

Ricardo Almeida concordou:

Serei bem franco: é claro que não existe nenhum caso que sustente crescimentos mensais de 200, 300%. Se fosse assim, a empresa dominaria o mundo em um punhado de anos! Mas eu tb tenho acompanhado o caso de alguns clientes que se estabilizaram em patamares muito altos. Não é pela tecnologia, é pela facilidade e experiência que proporciona aos usuários.

Agora, o fato de trazerem um retorno grande a curto prazo, obviamente, não significa que elas trarão prejuízo a médio prazo. Novamente, entra aí o planejamento e a gestão com base em métricas. que é importante para qualquer tipo de projeto, seja RIA ou não...

e Fernando Salvi fechou com classe:

Visitei hoje o penatrilha.com.br tendo em mente a discussão aqui na lista (muito boa, diga-se de passagem) e tô achando muito interessante os aspectos levantados por todos até agora...

Antes de mais nada, minha opinião se baseia exclusivamente na observação e uma avaliação heurística muito simples, digamos: "informal"...

Entendo que o uso de RIA tem potencial, mas não necessariamente, por si só, melhora a experiência do usuário. Acho que todos que comentaram aqui tmb pensam
assim. Independente da tecnologia (fugindo de "discussões religiosas", como citou o Ricardo), é preciso fazer o "arroz com feijão" muito bem feito pra se obter resultados excepcionais. "Arroz com feijão" leia-se: análise estratégica, focus groups, AI, análise de tarefas, protótipos, testes de usabilidade e mais um monte de técnicas e ferramentas usadas no projeto como um todo. E, acima de tudo, foco no usuário.

Bom, por que não então examinarmos o site como uma experiência online, deixando de lado o fato de ser uma RIA ou não? Seguem aí minhas singelas observações:

1) Busca: busquei por "calça". Tive que clicar no botão OK pois o enter não funcionou. Nos resultados, nenhum produto encontrado, mesmo apesar de existir até uma subcategoria "Calças" dentro do menu "Vestuário". Tentei novamente, agora sem cedilha (calca) e finalmente encontrei 63 produtos, entre eles: meias, tênis, sandálias, mochilas e bonés. Ah, sim, e algumas calças também.

- Possível problema: o cliente não encontra o que procura e deixa de comprar determinado produto.
- Possível benefício caso o problema fosse resolvido: aumento de vendas e faturamento.
- Complexidade para a solução do problema: mínima.

2) Ao visualizar um produto, não existe nele um link para a categoria na qual está localizado, impedindo que eu veja produtos similares.

- Possível problema: o cliente pode achar que não existem mais produtos como
aquele que ele está vendo.
- Possível benefício caso o problema fosse resolvido: aumento do faturamento (e
até mesmo aumento de ticket médio)
- Complexidade para a solução do problema: mínima

3) Na lista de produtos, não é exibido o nome do produto em si (ex: calça) e sim apenas o nome do fabricante e o modelo (ex: Solo Moment). Isso exige que o usuário clique em produto por produto para saber mais detalhes. E quando abre a janela de detalhes, essa informação existe mas fica escondida. Um exemplo: na seção de jaquetas: "abrigo de chuva", "parka" e "jaqueta" são fisicamente muito parecidos e inclusive exibidos na mesma categoria. Entretanto, cada produto desses podem ter aplicações muito diferentes (neve, frio, chuva, etc). Se o usuário procura por uma parka, então deve clicar em um por um dos produtos pra saber o que é cada um.

- Possível problema: irritação do cliente causado pela sobrecarga de cliques e vai-e-volta; cliente pode não encontrar o produto apesar de ele existir
- Possível benefício caso o problema fosse resolvido: aumento nas vendas e
satisfação do cliente.
- Complexidade para a solução do problema: mínima

4) O link para "próxima página" quando são exibidos mais de 15 resultados está localizado numa posição não convencional (acima, à direita), mas isso, claro, não quer dizer que não poderia estar lá. Entretanto, soma-se a esse detalhe o
fato dos botão que levam para as outras páginas (1, 2, 3, etc) são bem pequenos e de pouco contraste. Possível problema: pode-se perder clientes e vendas pois alguns usuários não perceberam que haviam mais produtos em outras páginas. Só por curiosidade, pedi pra duas pessoas entrarem na mesma página e de cara os dois tiveram o mesmo comportamento que eu: moveram o mouse até a parte de baixo da tela, onde supostamente deveria o link para outras páginas se houvesse. Na dúvida, clicaram em Back do browser. Nessa, volta-se ao "Loading..." da home e começa tudo de novo.

- Possível problema: abandono do site causado pelo Back; cliente pode achar que
loja não tem variedade e pode deixar de comprar produtos
- Possível benefício caso o problema fosse resolvido: aumento nas vendas,
satisfação do cliente e taxa de conversão.
- Complexidade para a solução do problema: mínima

5) "Cadastre-se": se eu bem entendi, posso me cadastrar para receber informações por e-mail (possivelmente lançamentos, promoções, etc). Entretanto, não tenho idéia do teor dos emails e da freqüência com que o site deve enviá-los portanto evito preencher com medo de receber mais spam. E, se
decidisse preencher, por que teria que informar RG e CPF? No meu ponto de vista, a única exigência desses dados seria se fizesse meu cadastro como cliente que vai efetivamente comprar pelo site (inclusive definindo senha de acesso e tal), mas esse cadastro não me pareceu ser o caso.

6) Processo de compra/pagamento: aqui esperava encontrar um fluxo bem mais simplificado, se comparado com o existente em sites convencionais (aka HTML), mas sinceramente não vi nada de diferente, ou melhor, nada que não pudesse ser feito com HTML, etc. O número de telas e cliques me pareceu o mesmo (apesar de que não me cadastrei e não vi o processo até o fim; meu comentário aqui é bem questionável). Do que vi, algumas mensagens de erro também poderiam aliviar o usuário (parecem apenas dizer o erro mas não sugerem possíveis soluções). E o botão "Continuar comprando" em amarelo no topo é mais saliente que o "Finalizar" em cinza, na parte de baixo.

- Possível problema: abandono do carrinho; confusão na tela de login, irritação
com msgs de erro não eficientes
- Possível benefício caso o problema fosse resolvido: aumento nas vendas e taxa
de conversão.
- Complexidade para a solução do problema: mínima

Fora isso, pra ser só um pouco mais chato (rs): texto muito pequeno em locais críticos (campos de input no processo de compra, msgs de erro). E também não posso aumentá-lo via browser.

Outra coisa que acho relevante discutir aqui é o impacto da "falta de estado" que me parece inerente a RIA. Como explicar... Vejamos: a sensação que tive ao navegar pelo site é de que estive sempre na home desde a hora que entrei no site... Isso se deveu ao fato de clicar num link e não existir uma transição clara do que ocorreu ou da mudança de uma página para outra. Então fiquei, em certos momento, sem perceber se meu clique "funcionou" ou em que área do site eu estava. Me pareceu uma mudança de um padrão de interação com o qual estamos acostumados e não sei se isso é bom ou ruim. De qualquer forma, não tenho dados nem conhecimento sobre este fator na usabilidade e experiência do usuário em RIA. Aliás, alguém tem algum dado desse tipo por aí?

De tudo isso, concluo algo muito parecido com o que o Irapuan já postou aqui (Ira, corrija-me se estiver errado :o): muita atenção e esforço em cima da RIA não resolve e não resolverá questões de usabilidade, AI, e etc. Faltou um detalhe que está acima das camadas de apresentação, tecnologia, etc: o cliente/usuário. Entendo que a RIA só pode ser realmente rich com um alicerce sólido de UCD.

Podemos usar a tecnologia que for, do fabricante que for, com a linguagem que for. Mas de uma coisa não podemos escapar: teste, teste e reteste com os usuários. Vale em paper, html, site no ar, whatever... Teste. Sempre.

RIA não é UX. É mais um (dentre os vários caminhos possíveis) pra se oferecer uma ótima UX.

Autor

Frederick van Amstel - Quem? / Contato - 15/12/2004

Redes

Siga-me no Twitter, Facebook, LinkedIn ou Instagram.

Citação

VAN AMSTEL, Frederick M.C. Rich Internet Applications: prós e contras. Blog Usabilidoido, 2004. Acessado em . Disponível em: http://www.usabilidoido.com.br/rich_internet_applications_pros_e_contras.html

Relacionados

Comentários

Diego Hordi
16/12/04 às 09:56

E aí galerinha...

Seguinte, concordo contigo Fred, e com o Irapuan. Também acho que o flash deve ser utilizado somente para o que ele serve: uma campanhazinha aqui, outra ali, outra acolá... Mas daí para sites institucionais inteiros, e-commerce, e outras aplicações muito mais complexas, acho uma grande perda de tempo dos desenvolvedores, de dinheiro dos "patrocinadores", e de paciência dos usuários. Afinal, haja saco para aguentar um "loading" a cada clique...

Interessantíssima esta discussão, porém, acho que os "desenvolvedores flash" deveriam citar exemplos mais plausíveis para a utilização desta ferramenta - para eu, visual - em aplicações ricas de internet.

Parabéns pelo blog, Fred.

Um grande abraço.

Everton, =[@rCeBiSpO]=
16/12/04 às 10:24

Fred,

Sinceramente? Nada contra os desenvolvedores em Flash (sou um inclusive), mas não vi nada em especial no exemplo penatrilha.com.br. Todos os comentários deste post são muito pertinentes, principalmente o último de Fernando Salvi. No exemplo citado, acredito o que site teria mais benefícios se fosse em Html. Tanto para usuários como para desenvolvedores.
Enfim, só uma opinião.

Fabrício
16/12/04 às 11:17

Bom,
Falar sobre RIA é algo muito complicado, como todos podem observar pelo calor da discussao acima.
Eu já tive uma conversa muito interessante sobre RIA com o Fred, nela falamos sobre desenvolvimento de portais em flash. Um pouco sobre o que conversamos:
Não acredito que RIA seja a solução de todos os problemas da internet (como diz a macromedia), porém para certos tipos de aplicação, é muito recomendado a utilização de RIA em outras não se deve usar RIA. O que acontece é que os desenvolvedores ainda não conseguiram largar o velho conceito do flash de loaders animações, designs super poluídos, etc... Se o foco da RIA for a diminuição de tempo de resposta ao usuário, sim, recomendo, caso contrário use HTML. Uma das coisas que mais me agradam no flash é a possibilidade de o usuário carregar apenas dados necessários para o seu propósito de visita, mas muitos desenvolvedores flash ainda insistem em sempre mandar algo inútl (como alguns efeitos de imagens, enfim, coisas enfadonhas, que enchem o saco de qualquer um). O que não pode acontecer (acredito eu) é que a questão de uso de tecnologia passe a ser apenas uma questão de filosofia de trabalho ficando assim o usuário em segundo plano (processo involuntário e inevitável, acredito eu). Acho q uma boa integração da equipe (criação, engenharia, arquitetura.....) e uma visão ampla do projeto por parte dessa, focada na experiência do usuário; passa por cima de toda e qualquer questão filosófica, extremista e fundamentalista. Bom, vou parar por aqui, se não meu comentário vai ficar maior que o post hehehehe.

Beck Novaes
16/12/04 às 11:46

Pena eu não ter entrado nessa conversa antes, pois acredito que posso acrescentar alguns detalhes não mencionados. Talvez isso seja ser assunto para um livro inteiro, tamanha a variedade conceitos envolvidos. Mas tentarei ser sucinto e ao mesmo tempo coerente.

Pelo que eu vi da discussão até agora, uma idéia chave não mencionada por ninguém se refere ao conceito Rich Client. E isto não é criação da Macromedia. Nos anos 90, com a programação Cliente x Servidor, havia diferentes tipos de abordagens para a camada Cliente. O Thin Client, define um cliente que tem a seu favor uma rápida inicialização; um ponto negativo fica por conta das várias chamadas que o cliente faz ao servidor para buscar mais recursos. O Fat Client, define um cliente que não precisa buscar recursos no servidor com freqüência, porém, um ponto negativo é o tempo de inicialização da camada cliente. Percebeu-se, portanto, que a melhor solução estava a meio caminho entre o Thin Client e o Fat Client: o Rich Client. É possível saber mais em: http://www-106.ibm.com/developerworks/web/library/wa-richcli.html

Dessa forma, podemos dizer que o Flash é “rico” no sentido em que é uma alternativa para a criação de aplicativos Rich Client para a WEB. E o HTML não é pobre porque não existe uma denominação Poor Client, mas ele é sim, uma espécie de Thin Client. A metáfora abaixo explica muito bem o modo ruim em que opera um aplicativo HTML.

[abre aspas]
Imagine que para cada refeição você tem que ir a uma mercearia e comprar apenas o que você precisa para aquela refeição. Se você esquecer um ingrediente, você tem que retornar a mercearia. Além disso, você sempre tem que jogar fora o que restar da refeição porque você não tem geladeira ou um armário para guardar os alimentos. Quando chega à hora de outra refeição lá vai você novamente para a mercearia, e isto vale para o almoço, o jantar ou o café da manha. E porque todos têm que fazer o mesmo que você, a mercearia está sempre congestionada.

Isto não é tão eficiente, não é mesmo? Entretanto, isto é basicamente como os Aplicativos Clientes para a Web funcionam. Quase todos os dados estão no servidor (a mercearia) e o usuário deve fazer várias tentativas demoradas de acessar estes dados, apenas para ser usado uma única vez de uma maneira extremamente controlada (basicamente um formulário de entrada e submissão de dados)."
[fecha aspas]

Fonte: http://www-106.ibm.com/developerworks/web/library/wa-richcli.html

O ponto chave aqui, e talvez o ponto mais importante de todos, é que estou falando de aplicativos. Aplicativo não é, por exemplo, um portal como o Terra, o UOL, ou similares.

Existem hoje no mercado várias iniciativas para trazer para a Internet o desenvolvimento Rich Client. Alguns exemplos são o XUL da Mozilla, o XAML da Microsoft, o AWT e Swing da Sun e SVG do W3C (Google para saber mais). A solução da Macromedia é o Flash. Eu acredito nesta solução, sobretudo, devido à ubiqüidade do Flash Player. É importante ressaltar que o ponto chave hoje é o Flash Player e não da ferramenta Macromedia Flash, uma vez que agora também é possível criar RIAs com o Flex. Apenas como referência, talvez seja interessante dar uma olhada no quanto o discurso da Microsoft se parece com o da Macromedia com relação à “um novo modelo” de desenvolvimento de aplicativos para a Web: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnintlong/html/longhornch01.asp

Beck Novaes
16/12/04 às 11:49

Continuando....

Mas por que RIA? Por que não chamar apenas de o “Rich Client da Macromedia”? Não posso afirmar qual foi a real intenção da Macromedia ao criar o acrônimo RIA. Mas eu o julgo pertinente, pois ao compararmos sua solução com a das outras empresas veremos que apenas o Flash tem a capacidade de incorporar de uma maneira “suave” som, vídeo e animações. Dessa forma, o Rich Client da Macromedia é diferente do Rich Client das outras empresas, que, na maioria das vezes, geram aplicativos com cara de desktop para a Web.

Com o Windows 3.11, podemos dizer que o “Drag And Drop” foi um grande avanço em termos de interface de usuário. Ao invés de decorar um comando para copiar um arquivo de um lugar para o outro você simplesmente arrasta de uma pasta para a outra. Mas o que aconteceu com este importante recurso na Web? Se até no Windows 3.11 nós tínhamos este recurso por que na Web não temos mais? Não parece uma volta ao passado? Este é apenas um exemplo das limitações do HTML para a criação de APLICATIVOS. De fato, muitos dos componentes das GUIs simplesmente não estão existem no HTML. Tomemos o DataGrid como exemplo. O HTML tenta simular este componente de interface de usuário com a Table. Mas este não é um grid de verdade. O usuário não pode aumentar o tamanho de uma coluna neste grid do HTML. Ele não pode trocar a ordem das colunas. Ele não pode ordenar os elementos do grid pela coluna. Você, como desenvolvedor, tente fazer este grid do HTML um grid editável e você ganhará uma grande dor de cabeça. Isso sem falar no problema do Refresh do HTML que a “metáfora da cozinha” descrita acima deixa bem claro.

Existe muito a falar ainda, mas gostaria de finalizar com apenas mais duas colocações.

1. A Programação Orientada a Objetos existe desde a década de 70, porém somente nos anos 80 foi ganhar a popularidade merecida, porque muitos não entendiam que se tratava de algo pertinente. Acredito que algo parecido acontece com as RIAs.

2. Se eu usasse as vantagens do Flash para dizer que o HTML não tem o seu espaço, eu estaria deixando de ver as vantagens do HTML. Acredito que algo parecido acontece com aqueles que argumentam contra o Flash. Ou seja, se apegam apenas no que conhecem de bom do HTML para argumentar contra o Flash. Da mesma forma, suponho que se desde o inicio tudo fosse Flash e hoje surgisse um tal de HTML, as pessoas estariam falando mal do HTML porque já conheceriam as vantagens do Flash.

[]'s
Beck Novaes

Agnaldo
07/01/05 às 09:56

Olá a todos, a tempos venho estudando uma forma de criar uma camada view forte, e o que percebi nestes anos falando de Aplicativos não sites, é...

(HTML / DHTML) é possivel criar componentes de grid e outros com esta tecnologia (projeto venus www.jbanana.org), o problema e a portabilidade entre browser (mozilla, ie). que vai consumir seu tempo, mas funciona muito bem.

XUL na minha opinião o modelo mais elegante de construir interface com usuário já tem componentes prontos e vc pode estendelos, desde de que conheça java e c, mas tem o esquema da portabilidade, o padrão de xml do xul eu acho muito bom.

Swing (www.swixml.org) tem que instalar a jre entre 40mb, bem usado pode ser leve e rápido o que não acontece com frequência, portabilidade ótima, a aplicação pode estar tanto em browser quanto em um webstart.

Flash tem alguns componentes, o resto vc tem que desenvolver como o dhtml(ou comprar), mas tem boa portabilidade visto que quase todo mundo que navega na internet com frequência tem o plug-in.

como eu pude ver já que pude desenvolver um aplicativo baseado em telas dhtml e outro em flash e que tem algumas facilidades que o flash/swing/xul oferecem que infelismente o dhtml não suporta como teclas de atalho, arastar e soltar(até tem mas o custo de desenvolvimento e meio alto) possibilidade de trabalhar com cache de telas, realmente usar a maquina do cliente para este trabalho controlar apresentação, isso diminui muito o uso de rede nas aplicações.

desculpem o tamanho do comentário, e que este assunto me interessa muito.

t mais

Ton
25/03/06 às 21:50

Estou de acordo com Beck Novaes.
Estes primeiros comentários "detonando" o RIA são provavelmente por pessoas com repressão a mudança e que provavelmente não estudaram afundo a tecnologia.
Todo ser humano é tem repressão a mudanças.
Há uma enorme diferença entre um site html e um em RIA. Claro, cada um no seu negócio.

Existem vários comentários infelizes acima...
Peguei dois aleatórios...
"Oh, claro, o HTML não tem texto voando, intermináveis transições e nem som. Dado o tempo que isso nos despediça, abençoado HTML."
-> Não da pra dizer que todos os sites feitos em flash são bons, existem muitos ruins, assim como existem muitos site horríveis em html, que poderia citar aqui. Comentário infeliz.

"Diante de tantas restrições que o Flash imputa ao usuário, ele merece ser chamado de "rico"?
-> Que restrições? Com certeza você não manja de flash.

CAPC-MEGADROM
09/07/07 às 04:01

Prezados colegas,

com poucas palavras deixo-lhes o útil:

flash só no que precisa trabalhar multimidea e animações... NUNCA faça o site todo em flash.. inomeras disvantagens que os maiores da internet sabem de cór e salteado... (Yahoo, Google, Microsoft, etc...)

percebam.. todas as empresas que criam seus produtos 100% em flash não da certo.... leiam sobre o http://www.goowy.com/ e leiam sobre o google maps ou yahoo mail... evidente que FLASH nao é uma boa plataforma "ainda".

Pra que Flash se vc tem XUL no FireFox, Mozilla e Internet Explorer?? (vide o QuiX - XUL Premier motor) que é uma solução AJAX pra alavancar Rich User Interfaces usando XUL.

Eu mesmo estou melhorando o QuiX pra ser ainda melhor e vou lançar um LGPL dele mais simples de se usar...

estudem mais a fundo "os porques" que os grandes players do mercado nao usam flash como base.... existem inumeras desvantagens de usar flash ao invez de conceitos AJAX.

ah... deem uma olhadinha no meu ultimo projeto AJAX: GoBits http://www.gobits.com/

dai depois de ver mais esse projeto (GoBits) eu pergunto: "pra que FLASH"? pra inviabilizar? so se for ne...?

CAPC

CAPC-MEGADROM
17/12/07 às 13:08

Disse que estava melhorando o QuiX pra rodar XUL em vários browser e fiz!

Vejam o www.openxul.com

Desfrutem da nova realidade WEB 2.0 e Interfacer Ricas sem FLASH... OpenXUL é o fruto de AJAX e Rich Interfaces by Mozilla's XUL

falow!