The killer ClubDelphi application... (antes: aportarias tu codigo?)

[Ñuño Martínez]

La idea de pequeños programas que trabajan conjuntamente me gusta. De hecho, mi opinión es que todas las aplicaciones deberían hacerse de esa forma.

Lo de un cliente de mensajería también me gusta. Ahora estoy usando GAIM (MSN y Yahoo! Messenger) y para correo utilizo SquirrelMail, que no está mal pero me mata con lo del SPAM y que no me marca como "no leídos" los mensajes que no estén en la bandeja de entrada...

Yo también voy a aportar mi propio proyecto:

Titulo:

Salamanca desktop.

Problema a resolver:

Aulas informáticas en colegios. Este año estuve como monitor en una y existían numerosos problemas:

Respecto a los usuarios, especialmente niños pero vale para cualquier usuario con poca experiencia,

• Les cuesta comprender el concepto de rendimiento, es decir, cómo afecta lo que hace el usuario a la velocidad del ordenador. En especial, los niños tienden a ser impacientes y pulsan los botones o los iconos varias veces si no hay una reacción inmediata, abriendo así varias instancias (ventanas) del mismo programa, haciendo que vaya aún más lento, haciendo que estén más impacientes, así que pulsan más veces... Es la pescadilla que se muerde la cola.
• Es difícil que entiendan que hay partes de la pantalla a la que no tienen acceso porque son bloqueadas por otra aplicación o por una ventana, por ejemplo, cuando aparece un mensaje de aviso o error.
• No saben qué hacer cuando aparece un aviso, especialmente problemático cuando una página web solicita que se instale un plug-in...
• Guardan una cosa (documentos, imágenes) y luego no pueden encontrarla, no borran lo que no necesitan...

Respecto a administrador, incluso el experimentado,

• Es difícil mantener todos los ordenadores con sus programas.
• Es difícil mantener todos los ordenadores sanos. Incluso es difícil programar una hora para una tarea. Varias veces dejaba a los ordenadores buscando errores en el disco de datos y ha aparecido algún profesor que necesitaba urgentemente utilizar uno de ellos...
• Es difícil saber dónde está el problema y quién lo estropeó, ya que todo el mundo mete mano: alumnos, profesores, técnicos... todos quieren instalar su programa, configurar el ordenador a su gusto, guardar sus datos ellos puedan encontrarlos, que nadie toque sus cosas...

Como se puede resolver

La idea que tenía era crear un sistema basado en cliente/servidor en el que el servidor (profesor o monitor del aula de informática) mantiene los usuarios y los programas que están instalados. Los programas se instalan y configuran en el servidor y este lo propaga en los clientes durante el encendido. El servidor también tendrá acceso a lo que están haciendo los clientes, incluso podrá intervenir para evitar actos no deseados.

Los usuarios (clientes) no tienen por qué usar siempre el mismo ordenador ya que los documentos se guardan en el servidor. El ordenador cliente hace una limpieza de sí mismo al encenderse, no al apagarse (los niños de 8 años tienden a apagar los ordenadores "a lo bruto").

Por último, que se note bien claramente qué ventanas se pueden utilizar y cuales no. Para ello veo dos soluciones:

• Sólo una aplicación puede estar activa en cada momento. Algo al estilo PalmOS, en la que sólo puedes acceder a una de las aplicaciones porque ocupan toda lapantalla.
• Sombrear las las ventanas inactivas, dejándolas en penumbra (o transparentes) en lugar de cambiar sólo el color de la barra de título.

Mercado objetivo:

Colegios, cyber, aulas informáticas en general...

Ejemplos de ideas similares:

No conozco ninguna, ni comercial ni gratuita.

Tareas a desarrollar

Pensado así, a lo bruto, casi habría que crear un sistema operativo... Tengo un documento por aquí con lo que pensé en su día. Si el proyecto interesa puedo subirlo a la red.

ES ASESINA PORQUE:

- Se podrá enseñar y gestionar un aula informática.

Porque es buen negocio hacerlo.

Hay escuelas y centros educativos que están pidiendo uno a gritos.

Bueno, aquí esta.

[[kuan-yiu]]

Me recuerda terriblemente a los "terminales tontos" que usé hace un montón de años en la facultad.

[Ñuño Martínez]

Pues precisamente me inspiré en los viejos terminales COBOL que utilizaba mi padre hace cuarenta años. Creo que para el ámbito educativo es lo mejor (o casi) ya que se puede controlar mejor.

Hay que tener en cuenta que no serían ordenadores de "propósito general" por lo que no importa si se les quita algo de "inteligencia".

[mamcx]

Creo que en este caso en vez de hacer un SO seria hacer un escritorio personalizado.

Se puede hacer un shell personalizado para Windows, como atestiguan quienes hacen software para cybercafe.

O un desktop para linux. Aunque eso me parece mas asustador

O algo mucho mas sencillo, una aplicacion de pantalla completa. Con sus propios iconos y ya es mas simple reposicionar ventanas al interior de esta.

Pero en ningun caso es tan simple. Ademas que requiere conocimientos de como reconfigurar (windows o linux), pero me parece posible.

[cancerbero]

Me parece una idea interezante para poder desarrollarla ademas q ayudaria al docente a poder controlar a los alumnos y podria realizar hasta un control sobre los examenes que el alumno daria para en base al desempeño del curso se pueda ver donde existen mas fallas en el aprendizaje, como un tutor inteligente, me gustaria participar del proyecto.

Cancerbero-Bolivia

[[Al González]]

¡Hola a todos!

En términos generales, estoy de acuerdo con Mario Montoya. Pero me parece importante que lo primero a definir sean las reglas generales de participación en este ejercicio de idealización colectiva de un proyecto de software. Una vez definidas esas reglas, pedirle a los moderadores que nos auxilien para hacer que se cumplan las mismas, y proceder a definir las etapas del proceso, las cuales sugiero sean o contengan a las siguientes:

1. Definición del modelo de trabajo. ¿Cómo vamos a trabajar una vez que se defina el producto de software a desarrollar? ¿Qué metodología emplearemos? ¿DTE, Extrema, etc.? Definir la forma en que los desarrolladores de Club Delphi (o de otras comunidades Web de programación) "deben" o pueden desarrollar este tipo de aplicaciones de forma Colaborativa y a distancia. Definir el modelo de trabajo sin pensar todavía en el producto, lenguaje de programación o sistema operativo; un modelo que nos sirva para éste y muchos otros desarrollos en grupo.

2. Definición del proyecto. ¿Qué vamos a hacer?
2.1. Lluvia de ideas bajo un esquema similar al propuesto por Mario:

• Nombre (título o nombre interno / temporal del proyecto de software).
• Objetivo (problema a resolver).
• Mecanismos (cómo se puede resolver o desarrollar algo así).
• Mercado (mercado objetivo bajo cualquier clasificación pero bien definido).
• Similitudes (ejemplos de otros productos similares ya existentes en el mismo mercado definido anteriormente).
• Ventajas y desventajas (puntos a favor y en contra del nuevo producto en comparación con otros similares, y otras razones de peso que se deban considerar como importantes factores de riesgo u oportunidad).
• Tecnologías (herramientas, lenguajes y bibliotecas de programación sugeridas o necesarias para el desarrollo de ese producto).

2.2. Votación de las ideas planteadas y determinación del producto de software a desarrollar.

3. Formación del equipo. Convocatoria para la integración del equipo de trabajo. Determinación de las áreas del proyecto que cada participante cubrirá en base a sus habilidades, disposición, interés, experiencia y gusto.

4. Análisis preliminar. Análisis general previo al desarrollo para confirmar la viabilidad del proyecto y poder estimar el tiempo y otros recursos necesarios para su desarrollo.

5. Estimación de costos. Análisis y determinación del tiempo necesario para el desarrollo del proyecto. Basado en la cantidad de horas que cada participante estime para cada una de las tareas que se le asignen, y considerando que en este caso se tratará de un desarrollo cooperativo donde no hay pago directo de honorarios.

6. Calendarización. Elaboración del calendario desglosado del proyecto, estableciendo las fechas de entrega para cada parte en que se divida el mismo (ejemplo: Juan necesita seis horas para el diseño visual de la pantalla de registro de usuarios, lo iniciará el 5 de septiembre y lo entregará el día 11).

Agradecería a los presentes que me ayudaran a mejorar el esquema que propongo, y que no se propongan más ideas de productos antes de dejar definido el esquema. Preparar la cancha antes de jugar en ella.

Un abrazo organizado.

Al González.

[[Al González]]

Empezado por Al González

¡Hola a todos!

En términos generales, estoy de acuerdo con Mario Montoya. Pero me parece importante que lo primero a definir sean las reglas generales de participación en este ejercicio de idealización colectiva de un proyecto de software. Una vez definidas esas reglas, pedirle a los moderadores que nos auxilien para hacer que se cumplan las mismas, y proceder a definir las etapas del proceso, las cuales sugiero sean o contengan a las siguientes:

1. Definición del modelo de trabajo. ¿Cómo vamos a trabajar una vez que se defina el producto de software a desarrollar? ¿Qué metodología emplearemos? ¿DTE, Extrema, etc.? Definir la forma en que los desarrolladores de Club Delphi (o de otras comunidades Web de programación) "deben" o pueden desarrollar este tipo de aplicaciones de forma Colaborativa y a distancia. Definir el modelo de trabajo sin pensar todavía en el producto, lenguaje de programación o sistema operativo; un modelo que nos sirva para éste y muchos otros desarrollos en grupo.

2. Definición del proyecto. ¿Qué vamos a hacer?
2.1. Lluvia de ideas bajo un esquema similar al propuesto por Mario:

• Nombre (título o nombre interno / temporal del proyecto de software).
• Objetivo (problema a resolver).
• Mecanismos (cómo se puede resolver o desarrollar algo así).
• Mercado (mercado objetivo bajo cualquier clasificación pero bien definido).
• Similitudes (ejemplos de otros productos similares ya existentes en el mismo mercado definido anteriormente).
• Ventajas y desventajas (puntos a favor y en contra del nuevo producto en comparación con otros similares, y otras razones de peso que se deban considerar como importantes factores de riesgo u oportunidad).
• Tecnologías (herramientas, lenguajes y bibliotecas de programación sugeridas o necesarias para el desarrollo de ese producto).

2.2. Votación de las ideas planteadas y determinación del producto de software a desarrollar.

3. Formación del equipo. Convocatoria para la integración del equipo de trabajo. Determinación de las áreas del proyecto que cada participante cubrirá en base a sus habilidades, disposición, interés, experiencia y gusto.

4. Análisis preliminar. Análisis general previo al desarrollo para confirmar la viabilidad del proyecto y poder estimar el tiempo y otros recursos necesarios para su desarrollo.

5. Estimación de costos. Análisis y determinación del tiempo necesario para el desarrollo del proyecto. Basado en la cantidad de horas que cada participante estime para cada una de las tareas que se le asignen, y considerando que en este caso se tratará de un desarrollo cooperativo donde no hay pago directo de honorarios.

6. Calendarización. Elaboración del calendario desglosado del proyecto, estableciendo las fechas de entrega para cada parte en que se divida el mismo (ejemplo: Juan necesita seis horas para el diseño visual de la pantalla de registro de usuarios, lo iniciará el 5 de septiembre y lo entregará el día 11).

Agradecería a los presentes que me ayudaran a mejorar el esquema que propongo, y que no se propongan más ideas de productos antes de dejar definido el esquema. Preparar la cancha antes de jugar en ella.

Un abrazo organizado.

Al González.

Pasaba por aquí para ver cómo va el proyecto.