Hoy estoy que parezco que tengo fiebre jeje.
Esto también era una petición de luisma, se quejaba de no poder ver los vídeos de mobuzz desde el lector de feeds. Así que ni corto ni perezoso escribimos un parser para mostrar el vídeo en un rss.
Como es habitual tienes que instalarlo en tu servidor para poder utilizar el script
Poco a poco estoy preparando la nueva versión de packito, esperemos que pronto deje de ser beta la 1.2 y pueda liberarlo.
Entre las novedades que estoy programando es la capacidad de utilizar json para definir las palabras claves, así pasa a ser más flexible.
También estoy preparando la posibilidad de comprobar varios archivos js, algo muy demandado por mi amigo luisma.
Y bueno la ultima característica es poder bajarte el código mootools con el combo que necesites.
He tardado bastante en publicar el psd pero hemos estado liado con bitacoras.com y twitterposter.com.
En esta segunda fase he creado un proyecto en googlecode para que podamos ir buscando y añadiendo cosas al asunto, como ya he dicho en los comentarios todos sois bienvenidos (si tenéis dirección en gmail).
Voy a intentar hacer una lista con todos los que se apuntan y así realizar grupos.
Y ahora toca hablar un poco sobre el contenido del proyecto.
job2time es un simple gestor de tareas, puede ser multiproyecto pero cada proyecto tiene su propia pagina y configuración. La idea de hacerlo con tonos grises es para poder cambiar los colores y personalizarlo.
Solo contiene 5 secciones:
Existe otra opción pero que no esta incluida que consiste en una sección de clientes para que ellos puedan reportar fallos, sugerencias o nuevas tareas.
1. Añadir historial Es como se ve en la imagen que puse sobre la interfaz, esa parte esta fija para que en ningún momento se pierda el foco. Lo único que hay que destacar es el reloj, que en vez de incluir un input para poner el tiempo transcurrido es un scroll al estilo itunes, el cual se puede pausar o cambiar el tiempo.
2. Añadir tarea Aquí no se pierde tiempo, se debería mostrar un campo con solo el nombre de la tarea (que sale en plan menú vertical con slide), todas las gemas opciones (usuarios, tiempo, prioridad) se configuran más tarde en cada bloque (estilo dashboard de apple, por detrás).
Cada tarea tiene su propio TODO list, cuantas veces hemos creado una tarea y apuntado lo que había que hacer? ademas ayuda al usuario que le toque hacerla.
Para que cada usuario sepa que tareas son nuevas o que prioridad tienen, cada bloque contiene una chapa que se puede cambiar al vuelo, estas chapas son configurables(color/texto).
3. Opciones del proyecto Para cambiar datos del proyecto (imagen, datos de la empresa, etc.).
4. Usuarios En esta sección se añaden los usuarios para cada proyecto, nada del otro mundo, una gestión sencilla con el nombre y departamento que pertenece. Esto es algo importante para poder aplicar tareas a diferentes usuarios o grupos (diseño/programación/maquetación/).
5. Informes De nada sirve un gestor de tareas si luego no sabemos cuanto hemos invertido en cada proyecto (personal/tiempo), muestra informes con plantillas diseñadas por el usuario. Esta sección necesita un formulario (que no esta estudiado) para seleccionar que tipo de datos salen en los informes, si no escoge ninguna plantilla se muestra con el diseño del interfaz.
La idea de este proyecto es poder usar todo sin tener diferentes paginas.
Algunas de las cosas que hay que definir son las pantallas de login para cada proyecto, el dashboard y las pantallas para los clientes.
Y como buenos diseñadores os adelantamos que no vamos a usar nada que se asemeje al lightbox :).
No hay nada mejor que escuchar las ideas de aquellos que viven el trabajo en sus carnes, que cosas son prescindibles en esta aplicación y cuales son importantes?.
En el comentario de Nordic acerca de las propiedades CSS comenta sobre la nomenclatura de ID y Class.
Me ha picado la curiosidad para saber que nomenclatura es la idónea para escribir CSS.
Existen 3 tipos:
Donald
Pcrusal
Raqueta#mi-contenedor#mi_contenedor#miContenedorNormalmente para los lenguajes de programación se utilizan los dos últimos, debido a que el guión medio no puede ir en las variables.
En PHP por ejemplo se suele usar el guión bajo para los nombres de las funciones, en Ruby se utiliza el ultimo.
La verdad es que no entiendo cual puede ser el correcto.
Yo suelo utilizar el primero porque las propiedades CSS se escribe con guión medio (background-color, font-size).
Aunque también es cierto que para diferenciar las propiedades de los nombres de las clases se suelen escribir de diferente forma.
¿Que nomenclatura es la más acertada?
Con el aniversario de Bitacoras.com llegan muchas novedades, una de ellas son los fichajes :P. Me alegra trabajar con mis nuevos compañeros (David, Luís y Raúl).
