DClick Team Weblog [pt] » Arquitetura da Informação http://blog.dclick.com.br Blog do time da DClick Tue, 11 May 2010 11:07:41 +0000 http://wordpress.org/?v=2.9.1 pt hourly 1 Formulários dinâmicos com validadores http://blog.dclick.com.br/2009/09/30/formularios-dinamicos-com-validadores/pt/ http://blog.dclick.com.br/2009/09/30/formularios-dinamicos-com-validadores/pt/#comments Thu, 01 Oct 2009 01:24:49 +0000 Pedro Silva http://blog.dclick.com.br/?p=2166 Twitter!

Em minha estréia, trago para você este script para agilizar a construção de formulários Flex, ele apenas aponta "o caminho", você deverá implementar com os demais validadores.

Para isso vamos começar pela classe Event. chamaremos essa classe de CustomEvent, seu objetivo será criar o validador dentro do evento (mx.events.FlexEvent) creationComplete do campo, para isto foi necessário adicionar três propriedades à classe, que são: validateType do tipo Object que receberá as informações para configurar o validador, o validator do tipo coringa para que fique mais fácil de trabalhar com vários validadores diferentes (aqui vou trabalhar apenas com mx.validators.StringValidator e mx.validators.EmailValidator), e a constante contendo o nome do evento que vai caracterizar a configuração que chamamos de VALIDATECHANGE.

PLAIN TEXT
ACTIONSCRIPT:
  1. package core.events
  2. {
  3.  
  4.         import flash.events.Event;
  5.        
  6.         import mx.events.FlexEvent;
  7.         import mx.validators.EmailValidator;
  8.         import mx.validators.StringValidator;
  9.        
  10.         public class CustomEvent extends FlexEvent
  11.         {
  12.                 static public const VALIDATECHANGE:String ='validatechange';
  13.                 private var _validateType:Object;
  14.                 private var _validator:*;
  15.                
  16.                 public function CustomEvent(type:String,validateType:Object, bubbles:Boolean=false,cancelable:Boolean=false)
  17.                 {
  18.                         super(type, bubbles,cancelable);
  19.                         setValidator(validateType);
  20.                 }
  21.  
  22.                 public override function clone() : Event {
  23.                         return new CustomEvent(CustomEvent.VALIDATECHANGE,validateType);
  24.                 }
  25.  
  26.                 public override function toString():String {
  27.                         return formatToString('CustomEvent','type', 'bubbles', 'cancelable', 'validateType','validator');
  28.                 }
  29.  
  30.                 public function get validateType():Object
  31.                 {
  32.                         return _validateType;
  33.                 }
  34.  
  35.                 public function get validator():*
  36.                 {
  37.                         return _validator;
  38.                 }
  39.  
  40.                 private function setValidator(params:Object):void
  41.                 {
  42.                         if(params.validateType.length <1){
  43.                                 return;
  44.                         }
  45.                         _validateType = params;
  46.                         switch(params.validateType){
  47.                                 case 'string':
  48.                                 case 'noblank':
  49.                                    _validator = new StringValidator();
  50.                                     if(params.message.length> 0){
  51.                     _validator.requiredFieldError =
  52.                     _validator.requiredFieldError =
  53.                     _validator.tooLongError =
  54.                     _validator.tooShortError = params.message;
  55.                                     }
  56.                                     _validator.minLength = 1;
  57.                                 break;
  58.                                 case 'email':
  59.                                _validator = new EmailValidator();   
  60.                                 if(params.message.length> 0){
  61.                                     _validator.requiredFieldError =
  62.                                     _validator.invalidCharError =
  63.                                     _validator.invalidDomainError =
  64.                                     _validator.invalidIPDomainError =
  65.                     _validator.invalidPeriodsInDomainError =
  66.                                     _validator.missingAtSignError =
  67.                     _validator.missingPeriodInDomainError =
  68.                                    _validator.missingUsernameError = params.message;
  69.                                 }                   
  70.                                break;
  71.                         }
  72.                     _validator.source = params.source;
  73.             _validator.property = params.property;
  74.                     _validator.required = params.required;
  75.                         _validator.triggerEvent = params.triggerEvent;           
  76.                     _validator.enabled = true;
  77.                 }               
  78.         }
  79. }

Os validadores são classes/tags separadas do campo, para agilizar o desenvolvimento precisamos dos validadores nos campos, para isso vamos manipular uma classe baseada no TextInput (spark.components.TextInput), de forma a permitir a passagem da configuração básica do validador na tag, trabalharemos com a tag CustomInput adicionando esses atributos, que são eles: validateType que distinguirá o tipo do validador, message contendo a mensagem que será enviada ao navegador em caso de erro, required caracteriza como requerido ou não, index que ocupará o lugar do id. Para manipulação interna foram criadas as propriedades: _initialized responsável por informar se é a primeira vez que o validador será criado,_params responsável por armazenar as configurações para criação do validador, e _validator o próprio validador.

PLAIN TEXT
ACTIONSCRIPT:
  1. package core.mxml
  2. {
  3.  
  4.         import core.events.CustomEvent;
  5.         import core.model.CustomModelLocator;
  6.        
  7.         import mx.events.FlexEvent;
  8.         import mx.utils.ObjectUtil;
  9.        
  10.         import spark.components.TextInput;
  11.  
  12.         [Event(name="validatechange", type="core.events.CustomEvent")]
  13.                
  14.         public class CustomInput extends TextInput
  15.         {
  16.  
  17.                 private var _initialized:Boolean = false;
  18.                 private var _params:Object       = {validateType:'',message:'',source:'',index:'',property:'text',required:false,triggerEvent:'change'};
  19.                 private var _validator:* ;
  20.                 private var _model:CustomModelLocator;
  21.                 private var _validateType:String;
  22.                 private var _message:String      = '';
  23.                 private var _required:Boolean    = false;
  24.                 private var _index:int;
  25.                 private var _source:String;
  26.                
  27.                 public function CustomInput()
  28.                 {
  29.                         _model = CustomModelLocator.getInstance();
  30.                         super();
  31.             addEventListener(FlexEvent.CREATION_COMPLETE,onCreationComplete);
  32.                 }
  33.                
  34.                 private function dispatchEventCustom():void{
  35.                         _params.validateType = _validateType;
  36.                         _params.message      = _message;
  37.                         _params.required     = _required;
  38.                         _params.source       = this;
  39.                         _params.index        = _index;
  40.                         dispatchEvent(new CustomEvent(CustomEvent.VALIDATECHANGE,_params));
  41.                 }
  42.  
  43.                 private function onCreationComplete(event:FlexEvent):void {
  44.                         id = this.id = super.id = name;
  45.             addEventListener(CustomEvent.VALIDATECHANGE,setValidator);
  46.                         dispatchEventCustom();
  47.                          _initialized = true;
  48.                 }
  49.                
  50.                 public function get validator():* {
  51.                         return _validator;
  52.                 }
  53.  
  54.                 private function setValidator(event:CustomEvent):void
  55.                 {
  56.                         enabled = true;
  57.                         _validator = event.validator;
  58.             _model[_source][event.validateType.index].validator = event.validator;
  59.                 }
  60.                
  61.                 public function get validateType():String
  62.                 {
  63.                         return _validateType;
  64.                 }
  65.                
  66.                 [Bindable(event="validatechange")]
  67.                 [Inspectable(enumeration="noblank,string,email", name='validateType')]
  68.                 public function set validateType(v:String):void
  69.                 {
  70.                         _validateType = v;
  71.                         if(_initialized){
  72.                                 dispatchEventCustom();
  73.                         }
  74.                 }
  75.                
  76.                 public function get message():String
  77.                 {
  78.                         return _message;
  79.                 }
  80.  
  81.                 [Inspectable(type='String', name='message')]
  82.                 public function set message(v:String):void
  83.                 {
  84.                         _message = v;
  85.                 }
  86.  
  87.                
  88.                 public function get source():String
  89.                 {
  90.                         return _source;
  91.                 }
  92.  
  93.                 [Inspectable(type='String', name='source')]
  94.                 public function set source(v:String):void
  95.                 {
  96.                         _source = v;
  97.                 }
  98.  
  99.                 public function get required():Boolean
  100.                 {
  101.                         return _required;
  102.                 }
  103.                
  104.                 [Inspectable(type='Boolean', name='required')]
  105.                 public function set required(v:Boolean):void
  106.                 {
  107.                         _required = v;
  108.                 }
  109.  
  110.                 public function get index():int
  111.                 {
  112.                         return _index;
  113.                 }
  114.  
  115.                 public function set index(v:int):void
  116.                 {
  117.                         _index = v;
  118.                 }
  119.  
  120.  
  121.         }
  122. }

Os campos serão criados no modelo da classe Form (mx.containers.Form), e como quero deixar meu formulário mais genérico, ou seja, quero que os ids, labels e validadores, sejam flexíveis, possibilitando uma criação dinâmica, foi criada então a tag CustomFormBase, que receberá os dados para configuração do formulário, dinamicamente, em uma única propriedade, e ainda receberá a ação do submit (que não foi trabalhada tão profundamente).

PLAIN TEXT
ACTIONSCRIPT:
  1. package core.mxml
  2. {
  3.         import core.model.CustomModelLocator;
  4.        
  5.         import flash.events.MouseEvent;
  6.        
  7.         import mx.collections.ArrayCollection;
  8.         import mx.containers.Form;
  9.         import mx.controls.Alert;
  10.         import mx.events.FlexEvent;
  11.         import mx.validators.Validator;
  12.        
  13.         import spark.components.Button;
  14.  
  15.         public class CustomFormBase extends Form
  16.         {
  17.                 public var send:Button;
  18.                 private var _source:ArrayCollection;
  19.                 private var _model:CustomModelLocator;
  20.                 private var _dataConfig:String;
  21.                
  22.                
  23.                
  24.                 public function CustomFormBase()
  25.                 {
  26.                         _model = CustomModelLocator.getInstance();
  27.                         super();
  28.             addEventListener(FlexEvent.CREATION_COMPLETE,doCreationComplete);
  29.                 }
  30.                
  31.                 private function doCreationComplete(event:FlexEvent):void
  32.                 {                       
  33.             send.addEventListener(MouseEvent.CLICK,submit);
  34.                 }
  35.                
  36.                 protected function submit(event:MouseEvent):void
  37.                 {
  38.                          var _validators:Array = new Array();
  39.                         for(var i:int=0;i<_source.length;i++){
  40.                 _validators.push(_source[i].validator);
  41.                         }
  42.                     _validators = Validator.validateAll(_validators);
  43.             if (_validators.length == 0) {
  44.                 Alert.show("Preenchimento correto", "SUCCESSO");
  45.             }
  46.                 }               
  47.  
  48.                
  49.                 public function get source():ArrayCollection
  50.                 {
  51.                         return _source;
  52.                 }
  53.                
  54.                 public function get dataConfig():String
  55.                 {
  56.                         return _dataConfig;
  57.                 }
  58.                
  59.                 [Bindable]
  60.                 [Inspectable(type='String', name='dataConfig')]
  61.                 public function set dataConfig(v:String):void
  62.                 {
  63.                         _dataConfig = v;
  64.                         _source = _model[v];
  65.                 }
  66.  
  67.                
  68.         }
  69. }

Nosso primeiro MXML é bem simples, utilizando a classe Repeater (mx.core.Repeater), dispondo as tag da maneira que desejamos que sejam vizualizadas. (atenção UX)

PLAIN TEXT
CODE:
  1. <mxml:CustomFormBase
  2.                 xmlns:fx="http://ns.adobe.com/mxml/2009"
  3.                 xmlns:s="library://ns.adobe.com/flex/spark"
  4.                 xmlns:mx="library://ns.adobe.com/flex/halo"
  5.                 xmlns:mxml="core.mxml.*">
  6.                 <mx:Repeater id="configure" dataProvider="{source}">
  7.                         <mx:FormItem label="{configure.currentItem.label}" width="100%">
  8.                                 <mxml:CustomInput width="100%"
  9.                                         source="{dataConfig}"
  10.                     name="{configure.currentItem.id}" 
  11.                     message="{configure.currentItem.message}"
  12.                     required="{configure.currentItem.required}"
  13.                     validateType="{configure.currentItem.validateType}"
  14.                     text="{configure.currentItem.text}"
  15.                     index="{configure.currentIndex}" />
  16.                         </mx:FormItem>           
  17.         </mx:Repeater>
  18.         <mx:FormItem width="100%" horizontalAlign="right">
  19.                  <s:Button id="send" label="Submit" />       
  20.         </mx:FormItem>
  21. </mxml:CustomFormBase>

Já que criamos um padrão de construção, vamos continuar nele, separando o ActionScript do MXML, durante a criação do arquivo de referência da aplicação.

PLAIN TEXT
ACTIONSCRIPT:
  1. package core.mxml {
  2.     import core.model.CustomModelLocator;
  3.    
  4.     import mx.collections.ArrayCollection;
  5.    
  6.     import spark.components.Application;
  7.  
  8.    
  9.    
  10.     public class CustomApplication extends Application
  11.     {
  12.        
  13.            
  14.         [Bindable] private var _model:CustomModelLocator;
  15.        
  16.         public function CustomApplication()
  17.         {
  18.             _model = CustomModelLocator.getInstance();
  19.             super();
  20.         }
  21.    
  22.         public function get dataConfig1():String
  23.         {
  24.             return _model.DATASOURCE1;
  25.         }
  26.        
  27.         public function get dataConfig2():String
  28.         {
  29.             return _model.DATASOURCE2;
  30.         }
  31.  
  32.     }
  33. }

E adicionamos os dados (fake) fixos.

PLAIN TEXT
ACTIONSCRIPT:
  1. package core.model
  2. {
  3.         import mx.collections.ArrayCollection;
  4.  
  5.         [Bindable]
  6.         public class CustomModelLocator
  7.         {
  8.                 public const DATASOURCE1:String =  'dataConfig1';
  9.                 public const DATASOURCE2:String =  'dataConfig2';
  10.                
  11.                 public var dataConfig1:ArrayCollection;
  12.                
  13.                 public var dataConfig2:ArrayCollection;           
  14.    
  15.                
  16.                 static private var instance:CustomModelLocator;
  17.                
  18.         static public function getInstance() : CustomModelLocator
  19.         {
  20.             if ( instance == null ){
  21.              instance = new CustomModelLocator(new CustomSingleton());
  22.             }
  23.             return instance;
  24.        }
  25.                
  26.                
  27.        public function CustomModelLocator(singleton:CustomSingleton)
  28.        {
  29.            if ( singleton == null ){
  30.                 throw new Error( "Construção inválida" );
  31.            }else{
  32.                 dataConfig1 = new ArrayCollection([
  33.                     {label:'Nome',message:'Nome inválido',validateType:'noblank',id:'nome',text:'Pedro Claudio',required:true},
  34.             {label:'E-mail',message:'E-mail inválido', validateType:'email',id:'email',text:'',required:true}
  35.                ]);     
  36.                 dataConfig2 = new ArrayCollection([
  37.             {label:'Endereço',message:'Endereço inválido',validateType:'noblank',id:'end',text:'',required:true },
  38.                         {label:'Bairro',message:'Bairro inválido',validateType:'noblank',id:'bairro',text:'',required:false},
  39.                         {label:'Cidade',message:'Cidade inválida',validateType:'noblank',id:'bairro',text:'',required:true }
  40.            ]);             
  41.            }                   
  42.        }
  43.    }
  44. }
  45. class CustomSingleton {}

Por fim nossa chamada mãe.

PLAIN TEXT
CODE:
  1. <mxml:CustomApplication
  2.         xmlns:fx="http://ns.adobe.com/mxml/2009"
  3.         xmlns:s="library://ns.adobe.com/flex/spark"
  4.         xmlns:mx="library://ns.adobe.com/flex/halo"
  5.         xmlns:mxml="core.mxml.*" viewSourceURL="srcview/index.html">
  6.         <mx:HDividedBox>
  7.                 <s:Panel width="350">
  8.                         <mxml:CustomForm dataConfig="{dataConfig1}"  width="100%" />
  9.                 </s:Panel>
  10.                 <s:Panel width="350">
  11.                         <mxml:CustomForm dataConfig="{dataConfig2}"  width="100%" />
  12.                 </s:Panel>
  13.         </mx:HDividedBox>
  14. </mxml:CustomApplication>

exemplo
source

Este material foi registrado no http://cookbooks.adobe.com, local onde, a comunidade de desenvolvedores e usuários de tecnologias Adobe, podem compartilhar informações. E ainda no http://blog.pcsilva.com, origem do post.

]]> http://blog.dclick.com.br/2009/09/30/formularios-dinamicos-com-validadores/pt/feed/pt/ 0 O valor das transições nos aplicativos RIA http://blog.dclick.com.br/2009/09/21/o-valor-das-transicoes-nos-aplicativos-ria/pt/ http://blog.dclick.com.br/2009/09/21/o-valor-das-transicoes-nos-aplicativos-ria/pt/#comments Mon, 21 Sep 2009 14:57:14 +0000 Luciano Lobato http://blog.dclick.com.br/?p=2103 Twitter!

Em um aplicativo RIA, numa mesma interface, um elemento pode ter múltiplos estados para dar suporte às atividades do usuário: contraído, expandido, em foco, aumentado, colapsado, visível, invisível, escondido etc. A transição é justamente como o elemento muda de um estado para outro. Dificilmente, em um projeto de aplicativo que dará suporte à processos de negócio, o cliente vai considerar as transições como uma funcionalidade, por isso este é uma dos aspectos mais depreciados no desenvolvimento de software, e muitas vezes, considerado pelos desenvolvedores como meras "firulas".

Mas será que as transições adicionam algum valor para os aplicativos? Quais são as funções das transições?

Comunicação

A principal função das transições é a de comunicar mudanças no estado da interface, e deste modo, ajudar o usuário a entender os relacionamentos entre estes estados. Contrapor usabilidade com transições, como alguns fazem, não faz o menor sentido neste contexto, pois elas podem ser úteis para reduzir a carga cognitiva no entendimento destas relações, aumentando assim a facilidade de uso, possibilitando que o usuário fique focado em sua atividade.

Naturalidade

No mundo analógico-físico, quando as coisas mudam de estado, elas não mudam instantaneamente. As coisas se movem, se deslocam, mudando do estado inicial pouco a pouco até chegarem no estado final. Não que tenhamos que emular o mundo analógico no digital, mas essa mudança gradual de um estado para outro torna a interface muito mais familiar aos usuários, e com isso, mais intuitiva.

Estética

A última função das transições é a função estética. Como diz Donald Norman, a beleza nas interfaces faz com que a facilidade de uso percebida seja maior. E por mais que possamos depreciar a função estética em aplicativos, achando que a arte deve ficar longe da tecnologia, somos geneticamente programados para sermos atraídos para coisas bonitas e nos afastarmos de coisas feias. A estética tem um grande impacto no valor afetivo que o usuário atribui à alguma coisa, inclusive à ferramentas digitais. Se um dos objetivos de um software é ser usado, é bom que o usuário não sinta repulsa por ele.

Ps. Mesmo assim, deixemos o "Skip Intro" morto e enterrado.

Nu Descendo a Escada

]]> http://blog.dclick.com.br/2009/09/21/o-valor-das-transicoes-nos-aplicativos-ria/pt/feed/pt/ 1 Wireframing Experiences and Applications with Flash Catalyst http://blog.dclick.com.br/2009/01/06/wireframing-experiences-and-applications-with-flash-catalyst/pt/ http://blog.dclick.com.br/2009/01/06/wireframing-experiences-and-applications-with-flash-catalyst/pt/#comments Tue, 06 Jan 2009 11:07:35 +0000 Luciano Lobato http://blog.dclick.com.br/?p=1308 Twitter!

Vídeo sobre como fazer wireframes com o Flash Catalyst. Um pouco longo (1 hora e 3 minutos) , mas bem didático.

]]> http://blog.dclick.com.br/2009/01/06/wireframing-experiences-and-applications-with-flash-catalyst/pt/feed/pt/ 0 Moonlight – clone do Silverlight para Linux http://blog.dclick.com.br/2008/12/03/moonlight-clone-do-silverlight-para-linux/pt/ http://blog.dclick.com.br/2008/12/03/moonlight-clone-do-silverlight-para-linux/pt/#comments Wed, 03 Dec 2008 15:51:52 +0000 Emil Beli http://blog.dclick.com.br/?p=1067 Twitter!

Novell iniciou a clonagem do Silverlight para Linux. Oficiais do Novell declararam que não é intensão competir com Adobe, mas deixar usuários do Linux permanecer com vantagem em todos os servicos.

Miguel de Icaza falou:

"To us it's more a matter of making sure that Linux remains a first class citizen on the Web. It's not a [question of whether] we like Flash more than Silverlight. We wanted to make sure that Linux users wouldn't be left out from any interesting Web content,"

Minha opinião é que simplesmente, quer ferrar Microsoft, como sempre, e como deve ser.

Fonte:

Linux Clone of Microsoft's Silverlight in Beta

]]> http://blog.dclick.com.br/2008/12/03/moonlight-clone-do-silverlight-para-linux/pt/feed/pt/ 1 Adobe Max 2008: Google Analytics Tracking For Adobe Flash http://blog.dclick.com.br/2008/11/19/adobe-max-2008-google-analytics-tracking-for-adobe-flash/pt/ http://blog.dclick.com.br/2008/11/19/adobe-max-2008-google-analytics-tracking-for-adobe-flash/pt/#comments Wed, 19 Nov 2008 11:31:04 +0000 Luciano Lobato http://blog.dclick.com.br/?p=928 Twitter!

Antes, para rastrear o comportamento dos usuários em sites e aplicativos que usam flash e flex, através do Google Analytics, era preciso fazer um monte de ajustes chatos e trabalhosos. Agora, lá na Adobe MAX, disponibilizaram uma library (open source) que facilita bastante:

http://analytics.blogspot.com/2008/11/want-to-track-adobe-flash-now-you-can.html

Abaixo um vídeo que explica melhor:

Documentação
Código para download

]]> http://blog.dclick.com.br/2008/11/19/adobe-max-2008-google-analytics-tracking-for-adobe-flash/pt/feed/pt/ 0 Nosso objetivo é desaparecer http://blog.dclick.com.br/2008/08/22/nosso-objetivo-e-desaparecer/pt/ http://blog.dclick.com.br/2008/08/22/nosso-objetivo-e-desaparecer/pt/#comments Fri, 22 Aug 2008 13:56:11 +0000 Luciano Lobato http://blog.dclick.com.br/?p=553 Twitter!

Desde as CUIs (Command-line User Interface), passando pelas GUIs (Graphical User Interface), e indo na direção das NUIs (Natural User Interface), registrou-se um aumento impressionante no uso do computador como ferramenta de suporte de tarefas principalmente cognitivas, e ao mesmo tempo, uma diminuição gradativa do computador.

Não é preciso ser historiador das ciências da computação ou profundo conhecedor da Interação Homem-Computador para perceber como o computador está em todo lugar atualmente. A revolução digital (clichê) já aconteceu e a computação ubíqua (o computador em todo lugar) se mostra cada vez mais próxima. Mas ao mesmo tempo, cada vez mais, o computador (tanto o hardware quanto o software) têm ficado mais invisivel para o usuário. Se o computador tem sido cada vez mais usado, ele também tem cada vez mais desaparecido.

Se no início, apenas os programadores mais cabeçudos conseguiam mexer nos enormes mainframes, atualmente existe um grande segmento do mercado (desde os miguxos que não param de enviar SMS até executivos de meia-idade interessados em monitorar o preço das ações) esperando pelo iPhone chegar no Brasil. E não se trata apenas de diferenças de tamanho da máquina que realiza as computações, mas principalmente do modelo de interação entre esses paradigmas e do que está no centro (foco) dessas interfaces. Enquanto nas CUIs, o usuário era obrigado a aprender a escrever uma nova linguagem arbitrária, no iPhone, até um bebê consegue brincar. Ao invés de obrigar o usuário a aprender uma nova linguagem, é de se esperar (regra básica de usabilidade) que o desempenho da tarefa seja muito mais natural, se utilizarmos uma linguagem que ele já domine.

Nesse sentido, a história das tecnologias de informação e comunicação tem demonstrado que quanto menos interface, mais livre o usuário estará para alcançar seus objetivos. A interface, vista por esse ângulo, é algo extremamente negativo, funcionando como uma corrente que prende e atrasa o usuário. Quanto mais visível for as informações ou as funcionalidades (o motivo do usuário usar o software, no final das contas), mais escondida será a interface. Quanto mais invisível a interface, mais natural será o modelo de interação, melhores níveis de desempenho (eficácia e eficiência) serão alcançados na tarefa, e mais satisfatório será o uso do software. Sendo assim, o objetivo de qualquer user experience designer (arquitetos da informação, designers de interação, designers de interface etc.), deveria ser o de sumir, de fazer o seu trabalho ficar invisível para o usuário. Sabe aquelas interfaces que mais chamam a atenção? São exatamente elas que na grande maioria das vezes, são apenas decoração e depois de pouco tempo, revelam ter graves problemas de usabilidade. Um dos fatores de destaques dos aplicativos web 2.0 (ou RIAs ou seja lá como vamos chamá-los) em comparação aos antigos aplicativos que se utilizavam do modelo de hipertexto é justamente a forma mais natural do usuário interagir com a interface e dela ir sumindo aos poucos.

Tufte, um dos gurus da área de design de informação, em seu livro The Visual Display of Quantitative Information, criou o conceito de taxa de tinta de dados (data-ink rate), que significa a proporção da tinta de um gráfico empregada para exibição de informação. Esse conceito pode ser demonstrado matematicamente nas fórmulas:

  • 1.0 - proporção do gráfico que pode ser apagado sem perda de informações (redundância e elementos gráficos que não representam nenhum dado)
  • Tinta de dados / total de tinta para imprimir o gráfico

Tufte fala para maximizar a taxa de tinta de dados dentro do possível, com o objetivo de aumentar a expressividade e a efetividade destas visualizações. Para ele, todo pedaço de tinta requer uma razão, e na grande maioria das vezes, esta razão deve ser a de apresentar informação. Gráficos devem direcionar a atenção do observador para o significado daquela representação. Um gráfico, acima de tudo, deve mostrar os dados.

Indo da mídia impressa para a mídia digital, Stephen Few traduz a afirmação do Tufte para o design de dashboards, criando o conceito de data-pixel ratio, ou seja, taxa de pixels de dados.

O conceito pode ser emprestado e utilizado na área de User Experience Design. Quanto maior a taxa de informação (conteúdo ou funcionalidade, dependendo do objetivo do aplicativo, site etc.), mais invisível a interface, e mais natural o tipo de interação e o desempenho da tarefa pelo usuário. Nosso objetivo então não é o de ganhar o Cannes ou virar case de originalidade, mas justamente o contrário, o de desaparecer.

]]> http://blog.dclick.com.br/2008/08/22/nosso-objetivo-e-desaparecer/pt/feed/pt/ 11 Polí­tica de Segurança no Java (Arquivo Policy) http://blog.dclick.com.br/2008/02/21/politica-de-seguranca-no-java-arquivo-policy/pt/ http://blog.dclick.com.br/2008/02/21/politica-de-seguranca-no-java-arquivo-policy/pt/#comments Thu, 21 Feb 2008 18:55:46 +0000 Leonardo Cabral http://blog.dclick.com.br/2008/02/21/politica-de-seguranca-no-java-arquivo-policy/ Twitter!

Na segurança estabelecida a partir do JDK 1.2, todo código carregado para a JVM passa por uma política de segurança para que não sejam realizadas operações não-autorizadas na máquina local do usuário. Com a inclusão do conceito de política de segurança é possível estabelecer permissões diferenciadas para as aplicações.

Essa política é estabelecia pelo policy. Cada usuário pode definir as suas políticas através do arquivo de policy que fica localizado no "{user.home}/.java.policy" ou definir diretamente na jre localizada na pasta "{java.home}/lib/security/java.policy".

A sintaxe deste arquivo é a seguinte:

grant [signedBy <signer>] [, codeBase <code source>] {
permission <class> [<name> [, <action list>]];
...
permissoin <class> [<name> [, <action list>]];
};

Exemplos:

ex1 - Para um applet ter acesso a um arquivo local, teria que ser inserido no policy o seguinte trecho:

PLAIN TEXT
CODE:
  1. grant {
  2. permission java.io.FilePermission "c:/meuArquivo.txt", "read";
  3. };

ex2 - Para especificar um jar ou uma classe para poder acessar todos os arquivos de uma determinada pasta, ficaria assim:

PLAIN TEXT
CODE:
  1. grant codeBase "file:C:/meuJar.jar" {
  2. permission java.io.FilePermission "c:/minhapasta-", "read";
  3. };

Existe uma ferramenta chamada Policy Tool, que vem com o jdk, que ajuda a montar esse arquivo de forma gráfica, mas eu prefiro fazer isso diretamente no arquivo. Para saber mais sobre o Policy Tool acessar o link http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/policytool.html

Cuidado com as alterações, pois elas pode deixar alguma brecha para programas maliciosos danificarem o pc, portanto tente ser sempre o mais restrito possível ao dar as permissões. Para ajuda na montagem do arquivo policy acessar o link http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html

]]> http://blog.dclick.com.br/2008/02/21/politica-de-seguranca-no-java-arquivo-policy/pt/feed/pt/ 0 Sistema Offline com flex e java http://blog.dclick.com.br/2008/02/20/sistema-offline-com-flex-e-java/pt/ http://blog.dclick.com.br/2008/02/20/sistema-offline-com-flex-e-java/pt/#comments Wed, 20 Feb 2008 11:31:12 +0000 Leonardo Cabral http://blog.dclick.com.br/2008/02/20/sistema-offline-com-flex-e-java/ Twitter!

Algum tempo atrás caímos num grande desafio. Desenvolver uma parte do sistema para o usuário trabalhar desconectado. Sem poder usar o Apollo, pois não estava na versão final e não era homologado pela empresa, e também sem poder instalar um servidor de aplicação na máquina do usuário. Estávamos desesperados, pois a única opção era desenvolver toda a parte do front novamente só que em AWT ou Swing. Agora imagina ter que desenvolver algo parecido com que o flex e capaz de fazer. Eu nem sabia por onde começar, pois nenhum usuário acostumado a usar o flex gostaria de usar uma tela feita nessas tecnologias, pois seria voltar ao passado.

Então num dia inspirado, veio a idéia: se o flex acessa JavaScript e o JavaScript acessa Applet e o Applet não precisa de servidor (executa só com o browser e o plugin do java). Porque não tentamos utilizar isso. Parecia loucura, mas foi isso que foi feito...

Como ficou dividido o sistema:

Arquitetura do Offline

  • Flex – Camada de apresentação que possui apenas os módulos disponibilizados no Offline.
  • Javascript – Responsável pela comunicação entre o Flex (swf) e o Applet (jar). Ele é apenas um redirecionador das requisições Flex para o Applet.
  • Applet – Classe Java que o browser consegue executar. Responsável por receber as chamadas do Javascript e direcionar para a regra de negócio no Back-End Local.
  • Back-End Local – Possui a regra de negócio no qual os módulos disponibilizados no Offline irão utilizar.

Exemplo para somar dois números:

Parte flex:

PLAIN TEXT
Actionscript:
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
  3.     <mx:Script>
  4.         <![CDATA[
  5.             import mx.controls.Alert;
  6.             public function call():void
  7.             {
  8.                 var result:Object = ExternalInterface.call("calljs", valor1.text,valor2.text);
  9.                 Alert.show(result.toString());
  10.             }
  11.         ]]>
  12.     </mx:Script>
  13.     <mx:Button click="call()" label="Chamar Back End" x="126" y="52"/>    
  14.     <mx:TextInput id="valor1" x="92" y="10" width="57"/>
  15.     <mx:TextInput id="valor2" x="217.5" y="10" width="63"/>
  16.    
  17. </mx:Application>

Acrescentar no index.template.html :

PLAIN TEXT
CODE:
  1. <script language="JavaScript">
  2.     function calljs(valor1,valor2)
  3.     {
  4.         ret = document.javaOffline.calcular(valor1,valor2);
  5.         return ret;
  6.     }
  7. </script>
  8.  
  9. <APPLET CODE="br.com.dclick.JavaOffline" WIDTH=1 HEIGHT=1 name="javaOffline">
  10. </APPLET>

Parte java:

PLAIN TEXT
JAVA:
  1. package br.com.dclick;
  2.  
  3. import java.applet.Applet;
  4.  
  5. public class JavaOffline extends Applet{
  6.    
  7.     public String calcular(String valor1,String valor2){
  8.         int v1 = 0;
  9.         try{
  10.             v1 = Integer.parseInt(valor1);
  11.         }catch (Exception e) {
  12.             return "Valor " + valor1 + "inválido ";
  13.         }
  14.  
  15.         int v2 = 0;
  16.         try{
  17.             v2 = Integer.parseInt(valor2);
  18.         }catch (Exception e) {
  19.             return "Valor " + valor2 + "inválido ";
  20.         }
  21.        
  22.         return "" + Util.somar(v1, v2);
  23.        
  24.     }
  25.  
  26. }

PLAIN TEXT
JAVA:
  1. package br.com.dclick;
  2.  
  3. public class Util {
  4.     public static int somar(int valor1, int valor2){
  5.         return valor1 + valor2;
  6.     }
  7. }

]]> http://blog.dclick.com.br/2008/02/20/sistema-offline-com-flex-e-java/pt/feed/pt/ 27 Design de Interface é algo para se discutir? http://blog.dclick.com.br/2007/07/10/design-de-interface-e-algo-para-se-discutir/pt/ http://blog.dclick.com.br/2007/07/10/design-de-interface-e-algo-para-se-discutir/pt/#comments Tue, 10 Jul 2007 11:50:06 +0000 Beck Novaes http://blog.dclick.com.br/2007/07/10/design-de-interface-e-algo-para-se-discutir/ Twitter!

Tenho notado que as discussões comunidade Flex de Língua Portuguesa são quase 100% voltadas para os aspectos internos (código fonte). Partindo do princípio que RIA tem muito a ver com Design de Interface eu pergunto: por que este assunto é tão pouco abordado pela comunidade?

Na época do Client Server o Designer nem fazia parte do time de criação de aplicativos. Graças à Web o Designer conquistou seu merecido espaço - embora ainda seja o alvo preferido das piadinhas dos desenvolvedores (os reis da cocada preta). Porém, a meu ver, existe muito Designer Gráfico (mais preocupado como Look and Feel do que com a funcionalidade) e Arquiteto de Informação (cuja própria descrição dá uma idéia do seu trabalho). Vejo muito pouco as pessoas falarem de Design de Interfaces e Design de Interação, essenciais para o sucesso de uma RIA. Por que será? Design de Interface é algo para se discutir? Se sim, por que isto não é discutido?

]]> http://blog.dclick.com.br/2007/07/10/design-de-interface-e-algo-para-se-discutir/pt/feed/pt/ 11