Advance Business Application Programming Código Ejemplo

noviembre 20, 2010 Deja un comentario

En esta entrada colocaré un código con ejemplos de Ciclos, querys con condiciones dinámicas y muchas cosas interesantes que les pueden servir! cualquier cosa que no entiendan estoy a sus órdenes, el código lo puse con muchos comentarios, pero si no entienden algo les puedo dar más detalles al respecto.

function znoel_colonias_adeudos.
*”———————————————————————-
*”*”Interfase local
*”  IMPORTING
*”     VALUE(ZCYTYNAME) TYPE  ADRCITYT-CITY_NAME OPTIONAL
*”     VALUE(ZPARTNER) TYPE  DPSOB_BP_ACC-PARTNER OPTIONAL
*”  TABLES
*”      T_OBJETO_UNICO STRUCTURE  ZST_NOEL_COL_ADEUDOS
*”      T_PERSONAS STRUCTURE  ZST_PERSONAS
*”  EXCEPTIONS
*”      NO_DATA
*”———————————————————————-

*&*********************************************************************
*&
*&  AUTOR: JLIRA
*&  FECHA MODIFICACIÓN: 28/09/10 – 08/10/10
*&
*&*********************************************************************

” Datos referente al manejo de los datos
data: it_adeudos1 type table of zst_noel_col_adeudos,
it_adeudos3 type table of zst_noel_col_adeudos,
“Tabla para obtener los BP únicos y poder consultar sus datos
it_adeudos2 type table of zst_noel_col_adeudos,
it_personas type table of zst_personas,

wa_col_adeudo1 like line of it_adeudos1,
wa_col_adeudo3 like line of it_adeudos3,

“WAs para obtener los datos de las personas con adeudos
wa_col_adeudo2 like line of it_adeudos2,
wa_personas like line of it_personas,

indice1 like sy-tabix,
indice3 like sy-tabix,
indice2 like sy-tabix,
annio type c length 4.

” Datos referente a la condición where del query
data: cond(72) type c,  ” variable para determinar nuestra condición
cl_estadistica type c value ‘G’,”Clave estadística
nodebe(1) type c value 9, “el 9 espara determinar que no esté
“compensado el pago
fecha type d, ” dato que tendrá la fecha de hoy para
” comparar las fechas vencidas.
itab like table of cond. “tabla donde se apendiza la variable

“Limpiamos nuestra variable INDICE e inicializamos el contador
clear: indice1, indice3.

” Asignamos la fecha de hoy
fecha = sy-datum.

if zpartner ne ”. ” si se busca por Colonia e Interlocutor comercial
concatenate ‘city~CITY_NAME = ”’ zcytyname ””  into cond.
append cond to itab.
concatenate ‘and df~GPART = ”’ zpartner ”” into cond.
append cond to itab.
concatenate ‘and DF~AUGST ne ”’ nodebe ”” into cond.
append cond to itab.
concatenate ‘and DF~STAKZ EQ ”’ cl_estadistica ”” into cond.
append cond to itab.
concatenate ‘and  df~FAEDN < ”’ fecha ”” into cond.
append cond to itab.

else. ” o en caso de que se busque solamente por colonia.
concatenate ‘city~CITY_NAME = ”’ zcytyname ””  into cond.
append cond to itab.
concatenate ‘and DF~AUGST ne ”’ nodebe ”” into cond.
append cond to itab.
concatenate ‘and DF~STAKZ EQ ”’ cl_estadistica ”” into cond.
append cond to itab.
concatenate ‘and df~FAEDN < ”’ fecha ”” into cond.
append cond to itab.

endif.

“IC      obj_cntr    CTA_cntr Unidad_E tipoCta
select distinct df~gpart acc~psobkey df~vkont be~swenr acc~kofiz
“num_doc  posición
df~opbel df~opupk
“Op.pral Op.parcl num.Colonia  Nom.colonia
df~hvorg df~tvorg city~city_code rc~mc_city1
“persona.nombre apellido1     apellido2
but~name_first but~name_last but~name_lst2
“calle   Demarcación Parcela1   Parcela2
rc~street pr~xgemark pr~nflurnr pr~xflurst
“Parcela.fracc Descuento Importe fechaIni fechafin
pr~brflurst df~sktpz  df~betrw df~bldat df~faedn

into table it_adeudos1 ” T_COLONIAS_ADEUDOS
from dfkkop as df
” Join por CTA_Contrato
inner join dpsob_bp_acc as acc on df~vkont = acc~partneracc

” Join por Interlocutor comercial
inner join but000 as but on acc~partner = but~partner
” Join por número de persona
inner join adcp as cp on but~persnumber = cp~persnumber
” Join por número de dirección
inner join adrc as rc on cp~addrnumber = rc~addrnumber
” Join por Interlocutor Comercial
inner join vibpobjrel as rel on rel~partner = acc~partner
” Join por Unidad económica
inner join vibdbe as be on rel~intreno = be~intreno
” Join por Unidad económica
inner join vibdpr as pr on pr~swenr = be~swenr
” Join por el nombre de la colonia
inner join adrcityt as city on rc~city1 = city~city_name
where (itab). ” Nuestro Where dinámico

“$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
if  sy-subrc <> 0. ” Revisamos que tenga datos nuestro query
raise no_data.
else. ” Si tiene datos empezamos las operaciones
” Empieza el ciclo para obtener el año
loop at it_adeudos1 into wa_col_adeudo1 from indice1.
add 1 to indice1.
“&———- Obtenemos el año en que se generó el adeudo ————
wa_col_adeudo1-annio =  wa_col_adeudo1-fecha_ini(4).
“&———–SE REALIZA LA MODIFICACIÓN A LA TABLA——————-
modify it_adeudos1 from wa_col_adeudo1
index indice1 “obtenemos el registro en el que se encuentra
transporting annio.
endloop. ” Termina Ciclo
clear indice1.

“Primero clonamos la tabla interna para hacer comparaciones
move it_adeudos1 to it_adeudos3.
it_adeudos1  = it_adeudos3.

“Ordenamos por OBJ. Contrato, CTA. Contrato y Año
sort it_adeudos1 by psobkey cta_contrato annio hvorg  tvorg.
sort it_adeudos3 by psobkey cta_contrato annio hvorg  tvorg.
“Borramos los duplicados de esos mismos campos para la tabla3
delete adjacent duplicates from it_adeudos3 comparing psobkey
cta_contrato
annio
hvorg
tvorg.

” ciclo para determinar los casos de op. principal y op. parcial
loop at it_adeudos1 into wa_col_adeudo1 from indice1.
add 1 to indice1.

if wa_col_adeudo1-hvorg eq 0001.”Op.principal Obtenemos las CxC
” Op. Parcial
” PREDIAL!!!!!!!!
” Impuesto Predial Corriente
if ( wa_col_adeudo1-tvorg eq 1001 or
wa_col_adeudo1-tvorg eq 1005 ).
wa_col_adeudo1-impuesto_pre = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting impuesto_pre.
” Impuesto Predial Rezago
elseif ( wa_col_adeudo1-tvorg eq 1009 or
wa_col_adeudo1-tvorg eq 1012 ).
wa_col_adeudo1-rez_imp_pre = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting rez_imp_pre.
” Multas predial
elseif ( wa_col_adeudo1-tvorg eq 4006 ).
wa_col_adeudo1-multas_pre = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting multas_pre.
” Gto notificación predial
elseif ( wa_col_adeudo1-tvorg eq 4023 ).
wa_col_adeudo1-gto_not_pre = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting gto_not_pre.
“LIMPIA!!!!!!!!!!!!!!!1
” Impuesto Limpia Corriente
elseif ( wa_col_adeudo1-tvorg eq 2485 or
wa_col_adeudo1-tvorg eq 2486 or
wa_col_adeudo1-tvorg eq 2487 ).
wa_col_adeudo1-impuesto_lim = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting impuesto_lim.
” Impuesto Limpia Rezago
elseif ( wa_col_adeudo1-tvorg eq 2480 or
wa_col_adeudo1-tvorg eq 2481 or
wa_col_adeudo1-tvorg eq 2482 ).
wa_col_adeudo1-rez_imp_lim = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting rez_imp_lim.
” Multas limpia
elseif ( wa_col_adeudo1-tvorg eq 4014 ).
wa_col_adeudo1-multas_lim = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting multas_lim.
” Gto notificación limpia
elseif ( wa_col_adeudo1-tvorg eq 4026 ).
wa_col_adeudo1-gto_not_lim = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting gto_not_lim.
endif.
“RECARGOS!!!!!!!!!!
elseif wa_col_adeudo1-hvorg eq 0002.

if ( wa_col_adeudo1-tvorg eq 0001 or
wa_col_adeudo1-tvorg eq 0002 ).
wa_col_adeudo1-recargos = wa_col_adeudo1-importe.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting recargos.
endif.
endif.

endloop. ” Termina Ciclo
clear indice1.

” Empieza el ciclo para comparar datos
loop at it_adeudos3 into wa_col_adeudo3 from indice3.
add 1 to indice3. clear indice1.
” Inicia nuestro Loop anidado para comparar registros
loop at it_adeudos1 into wa_col_adeudo1 from indice1.
add 1 to indice1.

“Revisamos que sea la misma cuenta contrato
if wa_col_adeudo1-cta_contrato eq wa_col_adeudo3-cta_contrato and
wa_col_adeudo1-annio eq wa_col_adeudo3-annio and
wa_col_adeudo1-hvorg eq wa_col_adeudo3-hvorg and
wa_col_adeudo1-tvorg eq wa_col_adeudo1-tvorg.

wa_col_adeudo3-multas_pre = wa_col_adeudo3-multas_pre +
wa_col_adeudo1-multas_pre.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting multas_pre.
wa_col_adeudo3-rez_imp_pre = wa_col_adeudo3-rez_imp_pre +
wa_col_adeudo1-rez_imp_pre.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting rez_imp_pre.
wa_col_adeudo3-impuesto_pre = wa_col_adeudo3-impuesto_pre +
wa_col_adeudo1-impuesto_pre.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting impuesto_pre.
wa_col_adeudo3-gto_not_pre = wa_col_adeudo3-gto_not_pre +
wa_col_adeudo1-gto_not_pre.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting gto_not_pre.
wa_col_adeudo3-multas_lim = wa_col_adeudo3-multas_lim +
wa_col_adeudo1-multas_lim.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting multas_lim.
wa_col_adeudo3-rez_imp_lim = wa_col_adeudo3-rez_imp_lim +
wa_col_adeudo1-rez_imp_lim.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting rez_imp_lim.
wa_col_adeudo3-impuesto_lim = wa_col_adeudo3-impuesto_lim +
wa_col_adeudo1-impuesto_lim.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting impuesto_lim.
wa_col_adeudo3-gto_not_lim = wa_col_adeudo3-gto_not_lim +
wa_col_adeudo1-gto_not_lim.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting gto_not_lim.
wa_col_adeudo3-recargos = wa_col_adeudo3-recargos +
wa_col_adeudo1-recargos.
modify it_adeudos3 from wa_col_adeudo3
index indice3
transporting recargos.
endif.
endloop.
endloop. ” Termina Ciclo para comparar datos

clear: indice1, indice3, it_adeudos1.

“Primero clonamos la tabla interna para hacer comparaciones
move: it_adeudos3 to it_adeudos2,
it_adeudos3 to it_adeudos1.”modificado 18/10/2010
it_adeudos3  = it_adeudos1.”modificado 18/10/2010
it_adeudos3  = it_adeudos2.

“Ordenamos por BusPartner, para poder borrar los repetidos
sort it_adeudos2 by buspartner.

“Borramos los duplicados de esos mismos campos para la tabla2
delete adjacent duplicates from it_adeudos2 comparing buspartner.

“Borramos las cta_contrato duplicadas
delete adjacent duplicates from it_adeudos1 comparing cta_contrato
annio.

” Formateo de la tabla it_adeudos1, para sumar todos los importes
” en una sola tupla.
loop at it_adeudos1 into wa_col_adeudo1 from indice1.
add 1 to indice1. ” para cada importe se inicializa a 0.0
“Predial
wa_col_adeudo1-multas_pre = 0.
wa_col_adeudo1-rez_imp_pre = 0.
wa_col_adeudo1-impuesto_pre = 0.
wa_col_adeudo1-gto_not_pre = 0.
“Limpia
wa_col_adeudo1-multas_lim = 0.
wa_col_adeudo1-rez_imp_lim = 0.
wa_col_adeudo1-impuesto_lim = 0.
wa_col_adeudo1-gto_not_lim = 0.
“Recargos aplica para ambos casos
wa_col_adeudo1-recargos = 0.
“Este campo ya no importa, pero tmb lo reseteamos
wa_col_adeudo1-importe = 0.
modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting multas_pre
rez_imp_pre
impuesto_pre
gto_not_pre
multas_lim
rez_imp_lim
impuesto_lim
gto_not_lim
recargos
importe.
endloop.

clear: indice1.

” Con este query llenamos nuestra tabla interna de personas
” con personas de la colonia con adeudos
select distinct but~partner acc~psobkey but~persnumber but~name_first
but~name_last but~name_lst2 rc~street
rc~house_num1 city~city_code rc~post_code1
rc~tel_number

into table it_personas

from but000 as but
inner join dpsob_bp_acc as acc on but~partner = acc~partner
inner join adcp as cp on but~persnumber = cp~persnumber
inner join adrc as rc on cp~addrnumber = rc~addrnumber
inner join adrcityt as city on rc~city1 = city~city_name
where city~city_name = zcytyname.

“empieza el ciclo para obtener las personas con adeudos
loop at it_personas into wa_personas.
loop at it_adeudos2 into wa_col_adeudo2.
if wa_personas-buspartner eq wa_col_adeudo2-buspartner.
append wa_personas to t_personas.
endif.

endloop.
endloop.

” Empieza el ciclo para obtener las cta_contrato únicas con sus
” Respectivas deudas, esto es solo por formato en Netbeans.
loop at it_adeudos1 into wa_col_adeudo1 from indice1.
add 1 to indice1.

loop at it_adeudos3 into wa_col_adeudo3.

if wa_col_adeudo1-cta_contrato eq wa_col_adeudo3-cta_contrato and
wa_col_adeudo1-annio eq wa_col_adeudo3-annio.

“Predial
wa_col_adeudo1-multas_pre   = wa_col_adeudo1-multas_pre +
wa_col_adeudo3-multas_pre.

wa_col_adeudo1-rez_imp_pre  = wa_col_adeudo1-rez_imp_pre +
wa_col_adeudo3-rez_imp_pre.

wa_col_adeudo1-impuesto_pre = wa_col_adeudo1-impuesto_pre +
wa_col_adeudo3-impuesto_pre.

wa_col_adeudo1-gto_not_pre  = wa_col_adeudo1-gto_not_pre +
wa_col_adeudo3-gto_not_pre.

“Limpia
wa_col_adeudo1-multas_lim   = wa_col_adeudo1-multas_lim +
wa_col_adeudo3-multas_lim.

wa_col_adeudo1-rez_imp_lim  = wa_col_adeudo1-rez_imp_lim +
wa_col_adeudo3-rez_imp_lim.

wa_col_adeudo1-impuesto_lim = wa_col_adeudo1-impuesto_lim +
wa_col_adeudo3-impuesto_lim.

wa_col_adeudo1-gto_not_lim  = wa_col_adeudo1-gto_not_lim +
wa_col_adeudo3-gto_not_lim.

“Recargos aplica para ambos casos
wa_col_adeudo1-recargos     = wa_col_adeudo1-recargos +
wa_col_adeudo3-recargos.

modify it_adeudos1 from wa_col_adeudo1
index indice1
transporting multas_pre
rez_imp_pre
impuesto_pre
gto_not_pre
multas_lim
rez_imp_lim
impuesto_lim
gto_not_lim
recargos.

“APPEND wa_personas TO T_PERSONAS.
endif.

endloop.

endloop.

clear: indice1, indice3.
“append lines of it_adeudos1 to T_COLONIAS_ADEUDOS.
append lines of it_adeudos1 to t_objeto_unico. “esto se debe modify

endif.

” Borramos contenido de la tabla y liberamos memoria.
free: it_adeudos1,
it_adeudos2,
it_adeudos3,
it_personas,
itab.

endfunction.

 

Categorías:Uncategorized

Corrupción y el Tránsito

julio 31, 2010 Deja un comentario

A cuantas personas no les ha pasado que un policía de transito solo los detiene para quitarles dinero? supongo que a varias, a mi ya me ha pasado, y una de las más chistosas (literal) fue cuando me querían poner una multa por llevar mi licencia que vencía dentro de un mes!!!! me dijeron que tenía que renovarla por lo menos un mes antes!! cosa que me dio mucha risa! jaja me querían cobrar por que mi licencia vencía en un mes! (al final no me quitaron nada) ya no saben que inventar los pobres policías deberían subirles un poco el sueldo para que no estén haciendo esas cosas.

Ahora que ya estoy un poco harto de estas situaciones me he tomado el tiempo de leer el REGLAMENTO DE TRANSITO DEL ESTADO DE PUEBLA, y dice muchas cosas curiosas y creo que deberíamos tomar muy en cuenta…

  • La primera que me gustaría comentar es la del artículo 86, el cual dice que cuando nosotros vamos a tomar un camión o bajar del mismo, este debe estar en ALTO TOTAL para poder bajar o subir de él, a cuantos no nos ha pasado que el camión ni se detiene y tu apenas estás subiendo un pie!, la solución para este problema si es que te molesta es denunciando el vehículo (camión, combí, eurovan, taxi etc…).

Si el mecanismo electromecánico (fue una pregunta de mi examen para la licencia, que son mejor conocidas                    como LUCES DIRECCIONALES) no funciona puedes sacar tu brazo izq. por la ventanilla izq. para hacer lo                      siguiente:

    1. Para detener los carros de atrás, solo tienes que sacar el brazo horizontalmente.
    2. Para dar vuelta a la izquierda lo extiendes para abajo.
    3. Para dar vuelta a la derecha lo extiendes para arriba.
  • Otro punto interesante es el del SEMÁFORO, los famosos colores VERDE, ÁMBAR Y ROJO.
    1. Verde significa que tienes libre paso.
    2. Ámbar solo es preventivo puedes pasarte el semáforo siempre y cuando no te alcance el ROJO.
    3. Rojo no puedes pasar, alto total.
  • Si vas a tomaste y eres conductor la multa es de 24 días de trabajo lo equivalente a 1320 pesos de hoy.
  • Una muy importante! no tienen derecho a detenerte solo para revisar tu vehículo, SOLAMENTE te pueden detener si cometiste alguna infracción.

Por último solo quisiera decir unas cuantas frases que no están en el reglamento son mis opiniones…

– Si vas a dar una vuelta en un lugar que está prohibido solamente no estorbes el tránsito!

– Si te vas a pasar un ALTO, no provoques un accidente!

Espero les guste el artículo que publiqué

Categorías:Uncategorized

No Es Suficiente Tiempo por Laura García

junio 16, 2010 Deja un comentario

Toda la vida hemos creido que jamás tenemos tiempo suficiente para terminar un trabajo; que jamás es suficiente el tiempo que nos dan de vacaciones. Jamás es suficiente el tiempo que tenemos para comer o dormir o reír o jugar.
Todo el tiempo es poco y cuando queremos que sea poco se vuelve mucho. Nos encontramos en el dilema de nunca estar satisfechos con lo que tenemos y pasamos la vida quejándonos de lo que en este momento nos hace falta.
El tiempo es relativo, ¿quien dice que no es suficiente?, ¿para quien no es suficiente?, ¿porqué no es suficiente? … ¿Realmente buscamos más tiempo del tiempo que tenemos? O simplemente es un capricho el buscarle más tiempo al tiempo.
Largo o corto, lo interesante es lo que pasa en ese momento que comienza y que deberá terminar ya sea a tiempo ó a destiempo.
El disfrutar, se esté haciendo lo que se esté haciendo, es la parte clave para dejar de pensar en la cantidad del tiempo y enfocarnos en la calidad del mismo.
En otras palabras vivamos el tiempo corto o largo, cambiante o estable, suficiente o insuficiente; y dejemos de lado los adjetivos que nos desvían del verdadro camino que nos llevan a conocer realmente el tiempo.
Tiempo, tiempo, tiempo…¿habrá tiempo para repetirlo varias veces?

Categorías:Uncategorized

Skinput: Approapriating the Body as an Input Surface

abril 29, 2010 Deja un comentario

I. Introducción

Devices with significant computational power and capabilities can now be easily carried on our bodies. However, their small size typically leads to limited interaction space and consequently diminishes their usability and functionality.

Appropriating the human body as an input device is appealing not only because we have roughly two square meters of external surface area, but also because much of it is easily accessible by our hands, also it can be arms, upper legs, torso etc…

Well in this paper I’ll describe the wearable sensor for bio-acoustic signal acquistion. And also to describe an analysis approach that enables our system to resolve the location of finger taps on the body. Finally I’ll describe the limitations of this sensor.

II. Related work

Always-Available Input

The primary goal of Skinput is to provide an always available mobile input system, that is, an input system that does not require a user to carry or pick up a device.

The SixthSense project [19] proposes a mobile, always- available input/output capability by combining projected information with a color-marker-based vision tracking sys- tem.

Always-Available Input

Signals traditionally used for diagnostic medicine, such as heart rate and skin resistance, have been appropriated for assessing a user’s emotional state.

These features are generally subconsciously- driven and cannot be controlled with sufficient precision for direct input. Similarly, brain sensing technologies such as electroencephalography (EEG) and functional near-infrared spectroscopy (fNIR) have been used by HCI researchers to assess cognitive and emotional state

There has been less work relating to the intersection of fin- ger input and biological signals. Researchers have har- nessed the electrical signals generated by muscle activation during normal hand movement through electromyography.

III. Skinput

Bio-Acoustics

When a finger taps the skin, several distinct forms of acous- tic energy are produced. Some energy is radiated into the air as sound waves; this energy is not captured by the Skin- put system.

Bones are held together by ligaments, and joints often include addi- tional biological structures such as fluid cavities. This makes joints behave as acoustic filters. In some cases, these may simply dampen acoustics; in other cases, these will selectively attenuate specific frequencies, creating location- specific acoustic signatures.

The prototype features two arrays of five sensing elements, incorporated into an arm- band form factor.

Base don pilot data Collection, the owners selected a diferent set of resonante frequencies for each sensor Packaged.

Each channel was sampled at 5.5kHz, a sampling rate that would be considered too low for speech or environmental audio, but was able to represent the relevant spectrum of frequencies transmitted through the arm.

For example, the ATmega168 processor employed by the Arduino platform can sample analog readings at 77kHz with no loss of precision, and could therefore provide the full sampling power required for Skinput (55kHz total).

Data was then sent from our thin client over a local socket to our primary application, written in Java. This program performed three key functions. First, it provided a live visu- alization of the data from our ten sensors, which was useful in identifying acoustic features. Second, it seg- mented inputs from the data stream into independent in- stances (taps). Third, it classified these input instances. The following figure show us a sample of the sensors.

IV. EXPERIMENT TEST

Methodology

To evaluate the performance of this system, 13 participants were recruited from the Greater Seattle area. These participants represented a diverse cross section of potencial ages and body types, ages between  20 to 56.

This methodology was divided in 5 diferents locations:

But just five fingers, whole arm and forearm were part of the test. Participants were seated in a conventional office chair, in front of a desktop computer that presented stimuli. For con- ditions with sensors below the elbow, the arm- band was placed ~3cm away from the elbow, with one sensor package near the radius and the other near the ulna. For conditions with the sensors above the elbow, the armband was placed ~7cm above the elbow, such that one sensor package rested on the biceps. Some of the results of the evaluation were:

Five Fingers

Despite multiple joint crossings and ~40cm of separation between the input targets and sensors, classification accura- cy remained high for the five-finger condition, averaging 87.7% (SD=10.0%, chance=20%) across participants. Seg- mentation, as in other conditions, was essentially perfect.

Whole Arm

Participants performed three conditions with the whole-arm location configuration. The below-elbow placement per- formed the best, posting a 95.5% (SD=5.1%, chance=20%) average accuracy. This is not surprising, as this condition placed the sensors closer to the input targets than the other conditions. Moving the sensor above the elbow reduced accuracy to 88.3% (SD=7.8%, chance=20%), a drop of 7.2%. This is almost certainly related to the acoustic loss at the elbow joint and the additional 10cm of distance between the sensor and input targets. Figure 8 shows these results.

The eyes-free input condition yielded lower accuracies than other conditions, averaging 85.0% (SD=9.4%, chance=20%). This represents a 10.5% drop from its vision- assisted, but otherwise identical counterpart condition.

Forearm

Classification accuracy for the ten-location forearm condi- tion stood at 81.5% (SD=10.5%, chance=10%), a surpri- singly strong result for an input set we devised to push our system’s sensing limit (K=0.72, considered very strong).

Walking and Jogging

The participants also do this test walking and Jogging, this can produce false positives (i.e., the system believed there was input when in fact there was not) and by the other hand true positives (i.e., the system was able to correctly segment an in- tended input).

Walking trials, the system never produced a false- positive input. Meanwhile, true positive accuracy was 100%. Classification accuracy for the inputs (e.g., a wrist

tap was recognized as a wrist tap) was 100% for the male and 86.7% for the female (chance=33%).

In the jogging trials, the system had four false-positive in- put events (two per participant) over six minutes of conti- nuous jogging. True-positive accuracy, as with walking, was 100%. Considering that jogging is perhaps the hardest input filtering and segmentation test, we view this result as extremely positive. Classification accuracy, however, de- creased to 83.3% and 60.0% for the male and female partic- ipants respectively (chance=33%).

Les recomiendo ver el ——>VIDEO SKINPUT MICROSOFT<——

Si quieren saber más de los autores de este proyecto da click AQUÍ, para descargar un documento Word donde explico brevemente otros proyectos de ellos.

Espero les haya interesado este artículo.

Categorías:Uncategorized

Paradigma y Estilos de Interacción

abril 19, 2010 5 comentarios

Proponer el uso de estilos y paradigmas de interfaces apropiados para distintos escenarios y aplicaciones.

Considerar los siguientes escenarios:

  • A) Un cliente de un banco que consulta saldos y realiza transferencias vía telefónica
  • B) Una visita guiada a un museo de arte utilizando un dispositivo móvil
  • C) Un equipo de desarrollo de software que se reúne semanalmente para discutir aspectos técnicos, revisar código y evaluar interfaces de usuario

1.- Un cliente de un banco que consulta saldos y realiza transferencias vía telefónica:

Estilo de uso:

El usuario marca al Banco y una vez que ingresa al sistema realiza lo siguiente:

  1. El sistema pide que seleccione una opción ( consultar saldo marque 1, realizar una transacción marque 2, volver a escuchar el menú marque 3).
  2. Una vez seleccionada una opción, supongamos que tecleo “1”.
  3. El sistema le pide que ingrese su número de cuenta.
  4. El usuario ingresa su número.
  5. El sistema confirma si existe el número de cuenta.
  6. El sistema pide el NIP al usuario.
  7. El usuario ingresa su NIP.
  8. El sistema confirma y le da el saldo actual de su tarjeta.

En dado caso de que haya presionado “2” solo agregaríamos los pasos:

  1. El sistema pide que ingrese la Fecha de vencimiento de la tarjeta.
  2. El sistema pide que ingrese el número de cuenta al cual desea hacer la transacción.

Podríamos concluir que es un paradigma autómata dado que sigue una secuencia de pasos. Por lo tanto el estilo sería menús y formas.

2.- Una visita guiada a un museo de arte utilizando un dispositivo móvil

Estilo de uso:

Un grupo de personas llegan al museo y en la entrada les dan un dispositivo móvil el cual dicen que los guiará durante su recorrido por el museo. el modo de interacción con el móvil es que el móvil les explicará la artesanía donde se encuentran actualmente y les dará toda la descripción sobre la artesanía, y si el usuario solicita más información lo puede hacer presionando las teclas o bien diciéndole al dispositivo que solicita “más información” y el dispositivo explicará más a detalles.

El paradigma seleccionado sería como Asistentes ya que es semi-autómata y el estilo sería como Agentes ya que toda la información actúa en favor del usuario.

3.- Un equipo de desarrollo de software que se reúne semanalmente para discutir aspectos técnicos, revisar código y evaluar interfaces de usuario

Un equipo se reúne semanalmente sin embargo no menciona que se tienen que reunir en algún lugar, incluso el mejor lugar para reunirse es cada quien en su casa utilizando una especie de Groupware, donde pueden evaluar las interfaces y discutir los aspectos técnicos.

Por otro lado para revisar el código es necesario que tengan el código, por lo tanto puede ser por la misma aplicación de Groupware y compartir archivos, en este caso sería código, pero no solo sería un Groupware el único medio, sino que también podría ser utilizando “Sky-Drive” donde pueden compartir archivos.

El paradigma relacionado sería Lugar de reunión, ya que el objetivo de este caso es que un grupo de personas se reúnan para revisar el código y discutir aspectos técnicos así como la evaluación de las interfaces.

El estilo sería Groupware ya que es una interacción humano-humano que facilita este tipo de interacción cuando no se encuentran en el mismo estado por ejemplo.

Categorías:Uncategorized

Estudio de Usabilidad de la aplicación web REC

enero 25, 2010 Deja un comentario

Introducción

Ingresamos por parejas a un estudio, el estudio tenía una computadora 2 sillas para que nos pudiéramos sentar a evaluar un software que estaba en la pantalla del monitor de esa computadora, ese software era una aplicación web llamada REC, más adelante explicaré de que se trataba.

Primero nos dieron una hoja que tenía puntos a evaluar y comentar, así como sugerir, para la aplicación, esa hoja incluía puntos para evaluar y comentar en equipo, sobre la apariencia de la aplicación, así como la forma de etiquetar sitios web, entre otras cosas.

REC

REC por sus siglas “Recomendaciones con etiquetado colaborativo”, es una aplicación web que tiene como objetivo principal el etiquetado de páginas web mejor conocidas como recursos, para realizar una clasificación por así decir, ya sea de “deportes, política etc…”, para así facilitar la búsqueda a los usuarios que estén interesados en cierta rama, ya que se pueden guiar por el número de usuarios que sugieren ese sitio.

Los puntos o elementos de la interfaz que se evaluaron fueron la forma o apariencia de la interfaz, así como colores, organización, nube de etiquetas, el campo de búsqueda, así como la forma en que te muestra los sitios populares y recientes, con respecto al campo de búsqueda la opinión de cómo te va sugiriendo las etiquetas conforme tecleas lo que buscas, esto con el fin de facilitar la búsqueda o tecleado de la búsqueda. También se evaluó la forma en como se etiquetan los recursos, la forma en que te muestra los resultados, si el orden en que se los presentaba al usuario eran correctos  y de que otra forma se podía presentar.

Al momento de desplegarte los resultados de alguna búsqueda podrías ver como cada recurso tenía una breve descripción, esta era el rating de la página, y cuantos usuarios la sugieren, cosa que me pareció muy interesante ya que si es muy visitada o sugerida la página era posible que el usuario encuentre lo que busque en aquella página.

Ya he hablado sobre la aplicación, ahora hablaré sobre como era el escenario donde realizamos la evaluación.

Éramos 2 personas José Luis Ramírez y su servidor Jorge Lira los cuales tomamos le papel de sujetos de un estudio de usabilidad, antes de entrar a la sala de estudio, tuvimos que esperar un rato en la antesala, la cual era muy a gusto, había unos sillones y una mesita, el lugar era silencioso ya que era en una biblioteca, misma donde nos hicieron firmar una carta donde no nos hacíamos responsables de los daños que le pudiéramos causar  al software, ya que la culpa era problema del creador y diseñador del software, misma donde nos afirmaba que nosotros íbamos a evaluar la aplicación web como un estudio de usabilidad de software y nos mostraron los derechos que teníamos al participar como sujetos en un estudio de usabilidad y el otro formulario que llenamos es de los sitios que conocíamos y en los que hacíamos búsquedas.

Al entrar en la sala de estudio en el cuarto piso de la biblioteca, había un escritorio con una computadora que contenía la aplicación,  junto con 2 sillas, al otro lado del escritorio se encontraba nuestro profesor el Doctor Alfredo Huitrón se podría llamar el “facilitador”, el cual nos fue guiando durante todo el proceso. La sala estaba a gusto ya que no había ruido y no había algún tipo de distracción que pudiera afectar durante el proceso, era la sala ideal para realizar el estudio de la usabilidad de la aplicación web.

Al momento de empezar a evaluar la aplicación, nos dieron una hoja con puntos a evaluar, criticar (constructiva), sugerir o comentar, los cuales fueron muy claros, conforme fuimos avanzando fuimos conociendo el software satisfactoriamente, el facilitador (Alfredo) nos fue guiando de forma correcta y eficiente, facilitó nuestras tareas de los elementos a evaluar durante el transcurso de la evaluación, creo que si se podrían realizar las mismas tareas sin el facilitador, pero hubiera sido más difícil y tardado el proceso.

Con respecto al tiempo fue más que suficiente, no nos iban correteando, íbamos con calma,  el tiempo fue suficiente para evaluar, opinar comentar con mi compañero y sugerir sobre los elementos, no solo el tiempo fue un factor importante sino que también la participación de mi compañero José Luis Ramírez ya que al ser 2 personas o sujetos podíamos comentar y así llegar a conclusiones sobre el sistema(aplicación), o sugerencias más objetivas para mejorar la eficiencia de la aplicación.

Ya explicado lo que realizamos ahora voy a explicar las 3 hojas que llenamos o mejor dicho formularios, en el primero nos pidieron nuestros datos y a comprometernos a evaluar la aplicación, el segundo fue un cuestionario sobre si conocíamos algunos buscadores mencionados en ese formulario, por último llenamos una dentro del estudio el cual tenía preguntas sobre que opinábamos sobre la aplicación evaluando si no mal recuerdo del 1 al 5, y si podíamos dar algunas sugerencias y comentarios al respecto, así como si me gustaría ser parte del proyecto es decir, etiquetar recursos. Todos los formularios llenados y contestados se me hicieron coherentes ya que siempre debe haber una especia de formalidad al momento de meterte a territorios que no son tuyos, y sobre todo la parte de la opinión personal ya que creo que eso puede ser de vital importancia para el desarrollador.

Durante el estudio fuimos grabados por una cámara Microsoft, a la cual no le dí importancia y seguí comentando como si no tuviera una cámara enfrente para así poder expresar todo con naturaleza. En general siento que en ese estudio frente a una cámara se puede decir que la cámara solo era para grabar los hechos “hablados” durante el proceso.

Categorías:Uncategorized

Pionero del campo IHC – Ben Shneiderman

enero 18, 2010 Deja un comentario

En este ensayo hablaré sobre uno de los pioneros del campo de interacción humano computadora, su  nombre es Ben Shneiderman nacido el 21 de agosto de 1947, el es un informático estadounidense. Su investigación principal como bien lo mencioné está relacionada con la Interacción Humano Computadora.

Ben Shneiderman actualmente es un Catedrático de la informática en el Laboratorio de Interacción Humano Computadora en la Universidad de Maryland en College Park. Con respecto a sus estudios él se graduó en la preparatoria de ciencias en Bronx y estudió la licenciatura de Física y Matemáticas en el City College de New York en 1968, y comenzó a estudiar Informática en la State University de New York, graduándose en 1972, y posteriormente terminó el doctorado en 1973. Shneiderman es conocido por la invención de los diagramas de Nassi-Shneiderman, una representación gráfica del diseño de software estructurado el cual explicaré más adelante.

También definió la Universal Usability, para llamar más la atención de la gran diversidad de usuarios de todos los diferentes países con diferentes lenguajes, culturas, incluso tamaños de pantalla, velocidad de las redes y plataformas tecnológicas implicadas en el diseño de interfaces de usuario.

Llevó a cabo experimentos en los cuales se concluye que los diagramas de flujo no son útiles para escribir, entender o modificar programas. En 1997 fue elegido como académico de la ‘Association for Computing Machinery’ (ACM).

En los últimos años ha trabajado en la Visualización de Información, creando los treemaps para el acceso a datos de tipo jerárquico. Ha desarrollado asimismo cursores para consultas dinámicas con múltiples gráficos coordinados que son los componentes principales de Spotfire, adquirido por TIBCO en 2007. Su trabajo continuó con herramientas visuales de análisis para series temporales de datos, TimeSearcher, datos multidimensionales, Hierarchical Clustering Explorer, y datos extraídos de redes sociales, SocialAction.

  • Nassi-Shneiderman

Simbolos utilizados en el diagrama:

Ejemplo de empleo:

  • 8 Reglas de oro para el diseño de las interfaces
  1. Esfuércese para el estado coherente
  2. Permitir a los usuarios frecuentes utilizar shortcuts
  3. Ofrecer retroalimentación
  4. Añadir un dialogo al campo de cierre
  5. Gestión de error
  6. Revocación fácil del permiso de acciones
  7. Soporte Interno
  8. Reducir la carga de memoria a corto plazo
  • Association for Computing Machinery.- Primera sociedad científica y educativa acerca de la computación.
  • Treemaps

Bibliografía

Categorías:Uncategorized